Reply by Harrold Spier February 6, 20032003-02-06

Although the char type is 8 bit, each char occupies one memory
word, because the DSP56xxx has no instructions to access one byte
efficiently.

By default the compiler does not clear or extend the excess bits
on a cast from a char or a short to an int or a long. For signed
values, the ANSI specification does not prescribe such behavior,
for unsigned values it requires overflow masking. By default the
compiler avoids the overhead involved by code to prevent overflows.
This is called 'Relaxed char/short arithmetic overflow masking'.

You can add the compiler option -AE to select forced conversions.

As you will see this will generate a lot of extra code. It is better
to avoid types smaller than int whenever possible, as they need more
instructions for conversions and do not save data space.

CrossView only evaluates the lower 8 bits of a word to get a
char value. To get the full 24 bits you can use the expression:

*((unsigned int *) &cksm)/n Harrold -----Original Message-----
From: John Wygonski [mailto:]
Sent: Wednesday, February 05, 2003 19:38
To:
Subject: [motoroladsp] unsigned char on Tasking C for DSP563xx Question for C implementation experts:

unsigned char cksm;
cksm = 0xFF + 0xFF;
if ( cksm != 0xFE ) { // this is a problem? }

I am using the C tools from Tasking. Tasking's compiler documentation
says that unsigned char is 8-bit, with a range of 0 to 255U.

Now, I know enough to pay attention to this sort of thing because
DSP563xx chip can only access 24-bit words in memory, but, my C-level
debugger reports cksm=0xFE, yet my code functions as if cksm=0x1FE.
Inspecting the asm produced by the compiler shows that indeed the 24-bit
quantity cksm (not
8-bit) is used to compare to 0xFF.

What should I expect the compiler to do here? Shouldn't I expect the
debugger from the same vendor to be consistent?

John Wygonski _____________________________________
Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer. You need to do a "reply all"
if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/


Reply by John Wygonski February 5, 20032003-02-05
Question for C implementation experts:

unsigned char cksm;
cksm = 0xFF + 0xFF;
if ( cksm != 0xFE ) { // this is a problem? }

I am using the C tools from Tasking. Tasking's compiler documentation says
that unsigned char is 8-bit, with a range of 0 to 255U.

Now, I know enough to pay attention to this sort of thing because DSP563xx
chip can only access 24-bit words in memory, but, my C-level debugger
reports cksm=0xFE, yet my code functions as if cksm=0x1FE. Inspecting the
asm produced by the compiler shows that indeed the 24-bit quantity cksm (not
8-bit) is used to compare to 0xFF.

What should I expect the compiler to do here? Shouldn't I expect the
debugger from the same vendor to be consistent?

John Wygonski