On 2013-02-08, Robert Henig <rhe...@redwoodsys.com> wrote:
> gSlaTxFrame.payloadPtr is a char*, so
> gSlaTxFrame.payloadPtr[gSlaTxFrame.pos]. You are more expert then me
> with compilers so I won't argue. But it is strange to me that or'ing
> char into the low byte of an unsigned short causes the high byte of
> the short to become 0xff.
You're not or-ing a char into the low byte of an unsigned short.
You're promoting a char to an short, and then or-ing that short short
into the destination unsigned short.
When the signed char is promited to a 16-bit integer, it is
sign-extended (that's what the sxt instruction is for).
0x00-0x7f promotes to 0x0000-0x007f
0x80-0xff promotes to 0xff80-0xffff
That's the way it works according to the C language standard.
If the sxt instruction wasn't there, the generated code would be
wrong.
> I will do some tests to verify.
>
> += instead of |= fixes the problem in the code.
Only if you can assume the low byte of the destination is 0x00 to
start with. If not, then you won't get the right result.
A better solution would probably be:
short-dest |= (unsigned char)whatever;
If you're just shuffling 8-bit wide chunks of data around, always,
always, always use unsigned char. Or better yet, uint8_t.
--
Grant Edwards grant.b.edwards Yow! Will the third world
at war keep "Bosom Buddies"
gmail.com off the air?
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
