Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

slip

signed integers and bit shifting

This topic is 5659 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

when performing a bit shift on a signed integer is the signed bit affected? thanks EDIT: I just found a document, http://www.freetype.org/pipermail/devel/2001-April/001954.html which contains: > For instance, if we need to shift right by 8 bits to make each of a, b, and c > fit into 24 bits of data, and a = FFFF8000 (-1.5), then a >> 8 is FFFF80. But > since these are stuffed into signed integer variables and the sign bit is not > lost when bit shifting signed integers, this is really FFFFFF80 for 32 bit > integers, and FFFFFFFFFFFFFF80 for 64 bit integers. As a 16.16 number, this > -0.0020 decimal. This doesn't look right to me! which is refering to "the sign bit is not lost when bit shifting signed integers". Could someone just confirm that for me please? thanks again [edited by - slip on June 16, 2003 7:57:50 PM]

Share this post


Link to post
Share on other sites
Advertisement
You might want to specify language and processor
Signed shifts in C are undefined (grr, stupid language defect).
x86 shr shifts in zeros, while sar copies the sign bit.

Share this post


Link to post
Share on other sites
Hey thanks,
I'm coding for the GBA and using C++.
EDIT: The GBA's CPU is an ARM7TDMI.

[edited by - slip on June 16, 2003 8:02:24 PM]

Share this post


Link to post
Share on other sites
I strongly suspect, that in C++, just as with C, as Jan mentioned, shifting a signed integer is undefined and so depends on what mood your compiler vendor was in .

The most sensible thing for a compiler vendor to do seems to be to use the arithmetic (sign preserving/extending) version of the shift for signed values.

In ARM asm you have ASR/ASL and LSR/LSL (IIRC) available for every instruction (in the same way as conditionals are).

If in doubt, on the GBA in particular just drop into inline assembler (ARM is really nice too, far more pleasant than x86)

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
Thanks S1CA,
I''ll write using >> and << shifts and if I have problems I''ll try using asm. =) Thanks for your help

Share this post


Link to post
Share on other sites
I just checked with a signed integer with Visual C++ 6.0. When shifting left, it used shl (the unsigned shift) but when shifting right it used sar (the signed shift). This is weird and a bug. You have to use sar/sal for signed and shl/shr for unsigned. You can do this with inline assembly. Also this only applies to Intel-based CPUs; I have no idea what the GBA instruction set is.

~CGameProgrammer( );

Share this post


Link to post
Share on other sites
quote:
Original post by Jan Wassenberg
You might want to specify language and processor
Signed shifts in C are undefined (grr, stupid language defect).
x86 shr shifts in zeros, while sar copies the sign bit.

What does SARs have to do with bit shifting?

Share this post


Link to post
Share on other sites
quote:
Original post by Jan Wassenberg
(grr, stupid language defect)



I don''t know the reasoning behind this decision, but nearly all "defects" like this in the C language are because it''s difficult/impossible to efficiently do it the same way across all platforms considered important by the committee.

Also, is the behavior of a bit shift defined for even unsigned int? (consider trap representations and padding bits)

Share this post


Link to post
Share on other sites
CGameProgrammer: no difference between sal and shl. It''s not a bug, it''s the right thing to do (although the standard doesn''t guarantee that every compiler and CPU can manage).

Russell: umm.. the arithmetic (signed) shift right instruction?

Share this post


Link to post
Share on other sites
Way Walker: it''s a throwback to some stupid 70''s mainframe that can''t cope. I don''t care about the mainframe now, but I do care about not being able to shift signed numbers (in a portable fashion).
To be fair, I can see why they did it (they want C programs to run on the mainframe; could have the compiler emit ''fix'' code, but that''s inefficient if you don''t need it), but it''s still annoying.

Indeed, it is defined. Trap representations can''t and won''t be generated from arithmetic on valid unsigned values.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!