signed integers and bit shifting
Author
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]
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.
Signed shifts in C are undefined (grr, stupid language defect).
x86 shr shifts in zeros, while sar copies the sign bit.
Author
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]
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]
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
. 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
Author
Thanks S1CA,
I''ll write using >> and << shifts and if I have problems I''ll try using asm. =) Thanks for your help
I''ll write using >> and << shifts and if I have problems I''ll try using asm. =) Thanks for your help
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( );
~CGameProgrammer( );
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?
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)
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?
Russell: umm.. the arithmetic (signed) shift right instruction?
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement