It is from JPEG official library.
#define MULTIPLY16C16(var,const) ((var) * (const))
#define FIX_0_211164243 FIX(0.211164243)
#define FIX_0_509795579 FIX(0.509795579)
#define FIX_0_601344887 FIX(0.601344887)
#define FIX_0_720959822 FIX(0.720959822)
#define FIX_0_765366865 FIX(0.765366865)
#define FIX_0_850430095 FIX(0.850430095)
#define FIX_0_899976223 FIX(0.899976223)
#define FIX_1_061594337 FIX(1.061594337)
#define FIX_1_272758580 FIX(1.272758580)
#define FIX_1_451774981 FIX(1.451774981)
#define FIX_1_847759065 FIX(1.847759065)
#define FIX_2_172734803 FIX(2.172734803)
#define FIX_2_562915447 FIX(2.562915447)
#define FIX_3_624509785 FIX(3.624509785)
#define ONE ((INT32) 1)
#define CONST_SCALE (ONE << CONST_BITS)
#define FIX(x) ((INT32) ((x) * CONST_SCALE + 0.5))
int workspace[32]; /* buffers data between passes */ // 2-Byte
integer arithmetic used
The first (muls) alternative:
if( wsptr[5] != 0 )
tmp0 += MULTIPLY16C16(wsptr[5], FIX_1_451774981); // sqrt(2) *
(c3+c7)
if( wsptr[3] != 0 )
tmp0 += MULTIPLY16C16(wsptr[3], -FIX_2_172734803); // sqrt(2) *
(-c1-c5)
if( wsptr[1] != 0 )
tmp0 += MULTIPLY16C16(wsptr[1], FIX_1_061594337); // sqrt(2) *
(c5+c7)
if( wsptr[5] != 0 )
tmp2 += MULTIPLY16C16(wsptr[5], -FIX_0_601344887); // sqrt(2) *
(c5-c1)
if( wsptr[3] != 0 )
tmp2 += MULTIPLY16C16(wsptr[3], FIX_0_899976223); // sqrt(2) *
(c3-c7)
if( wsptr[1] != 0 )
tmp2 += MULTIPLY16C16(wsptr[1], FIX_2_562915447); // sqrt(2) *
(c1+c3)
Second (__lmul__) alternative:
if( wsptr[5] != 0 ) {
tmp0 += MULTIPLY16C16(wsptr[5], FIX_1_451774981); // sqrt(2) *
(c3+c7)
tmp2 += MULTIPLY16C16(wsptr[5], -FIX_0_601344887); // sqrt(2) *
(c5-c1)
}
if( wsptr[3] != 0 ) {
tmp0 += MULTIPLY16C16(wsptr[3], -FIX_2_172734803); // sqrt(2) *
(-c1-c5)
tmp2 += MULTIPLY16C16(wsptr[3], FIX_0_899976223); // sqrt(2) *
(c3-c7)
}
if( wsptr[1] != 0 ) {
tmp0 += MULTIPLY16C16(wsptr[1], FIX_1_061594337); // sqrt(2) *
(c5+c7)
tmp2 += MULTIPLY16C16(wsptr[1], FIX_2_562915447); // sqrt(2) *
(c1+c3)
}
----- Original Message -----
From: "Ben Combee" <[EMAIL PROTECTED]>
To: "Palm Developer Forum" <[EMAIL PROTECTED]>
Sent: Friday, January 10, 2003 10:49 PM
Subject: Re: CW compiler
> At 22:19 2003-1-10 +0100, you wrote:
> >I just observed very strange thing.
> >
> >By changing the source line order the same source line (multiplication)
is
> >translated either into
> >
> > movea.w d4,a0
> > move.l a0,86(a7)
> > move.l a0,d0
> > move.l #-1730,d1
> > jsr __lmul__
> > move.l d0,d3
> >
> >or into
> >
> > move.w d6,d3
> > muls.w #-1730,d3
> >
> >The second alternative seems to be optically shorter, but it actually
uses
> >register value inherited from the previous code. That's OK.
> >What I don't understand is that in one case the multiplication is
realized
> >via muls instruction, in the other a call to the emulator is used
instead.
>
> Could you show the lines of code? The first one is doing a signed 32-bit
> multiplication, while the second is doing a signed 16-bit
> multiplication. Is it possible that with one line order, you've got a
long
> temporary result that's affecting the multiplication?
>
> --
> Ben Combee <[EMAIL PROTECTED]>
> CodeWarrior for Palm OS technical lead
> Palm OS programming help @ www.palmoswerks.com
>
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
