Re: Build jcpalm library with cw9.2

[Ben Combee]

At 07:45 PM 1/26/2004, Regis St-Gelais wrote:
unsigned char uchrI[10];
int intJ;
uchrI[5]=129;
intJ=uchrI[5];
if (intJ<0)    // Here the debuger tells me that intJ has a value of 129
(0x0081 in hex) which is positive for an integer
    {
    intJ=0;        // but the value is evaluated to a negative value and the
condition become true for intJ>=128
    }
OK, so I just tried this with the current 9.3 68K compiler:

static void foo()
{
00000000: 4E56 0000          link      a6,#0
uchrI[5]=129;
00000004: 1B7C 0081 0000     move.b    #-127,uchrI+$05
intJ=uchrI[5];
0000000A: 7000               moveq     #0,d0
0000000C: 102D 0000          move.b    uchrI+$05,d0
00000010: 3B40 0000          move.w    d0,intJ
This code is writing the "129" value out to memory as a byte, and reading 
it back in as a unsigned value (the top byte of d0 is 0, while the bottom 
has the value from uchrI[5].

if (intJ<0)
    {
00000014: 4A6D 0000          tst.w     intJ
This instruction tests the value of intJ against zero.

00000018: 6C04               bge.s     *+6            ; 0x0000001e
            intJ=0;
    }
so if intJ >= 0. jump over the code that clears intJ.

0000001A: 426D 0000          clr.w     intJ

0000001E: 4E5E               unlk      a6
00000020: 4E75               rts
}
This all looks valid to me.  However, I thought there could still be a 
problem, so I moved those variables to be local to the function.  Now I get:

static void foo()
{
unsigned char uchrI[10];
int intJ;
00000000: 4E56 FFF6          link      a6,#-10
uchrI[5]=129;
00000004: 1D7C 0081 FFFB     move.b    #-127,-5(a6)
intJ=uchrI[5];
0000000A: 7000               moveq     #0,d0
0000000C: 102E FFFB          move.b    -5(a6),d0
if (intJ<0)
    {
00000010: 6C02               bge.s     *+4            ; 0x00000014
            intJ=0;    }
00000012: 7000               moveq     #0,d0
00000014: 4E5E               unlk      a6
00000016: 4E75               rts
}
This code is mostly the same, except that there's no write to memory to 
store intj and reload.  However, this is bad codegen, as the negative flag 
is set based on the byte value written, not the full word in D0.

I don't yet know when this bug was introduced into the compiler, but I'm 
going to get it fixed ASAP, and the fix will be in 9.3.  Thanks for the report! 

--
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palmos.com/dev/support/forums/