At 23:24 2003-1-10 +0100, you wrote:
I would think so... although remember that 68K assembly code is written source then destination, so your last line is reallyPerhaps one additional information. Bellow is a longer excerpt from the translation. (muls alternative).tmp0 = MULTIPLY16C16(wsptr[7], -FIX_0_211164243); move.w d6,d3 muls.w #-1730,d3 if( wsptr[5] != 0 ) move.w 10(a2),d7 beq.s *+10 ; 0x00000398 tmp0 += MULTIPLY16C16(wsptr[5], FIX_1_451774981); move.w d7,d0 muls.w #11893,d0 add.l d0,d3 if( wsptr[3] != 0 ) move.w 6(a2),136(a7) beq.s *+12 ; 0x000003aa My interpretation is following: (short)*(short) -> (long)D3 (short)*(short) -> (long)D0 (long)D0 += (long)D3 That should be OK, shouldn't be?
(long)D3 += (long)D0
However, I think I see a problem from your other message. The macro FIX(x) is defined as
#define FIX(x) ((INT32) ((x) * CONST_SCALE + 0.5))
This is causing all the FIX_number macros to be cast to 32-bit integers, which forces the multiplication to be 32x32. I don't know what's in the MULTIPLY16C16 macro, so maybe it undoes the cast by casting everything to INT16's. If it doesn't then that could lead to __lmul__ call generation.
I'm not sure why a reorder would matter, but having both tmp0 and tmp2 in the same scope would increase the virtual register pressure, affecting code generation. Still, the compiler shouldn't call __lmul__ unless really needed.
--
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/
