About shift one number more than 32.

[L.G]

I met one problem of shift a number with equal or more than 32 bits.

When running this :

uint32_t num = 0x45F5F;
int shift = 33;
uint32_t res = num << shift;

printf( "\\> exp: %08XH << %d = %08XH\n", num, shift, res );

It shows :

\> exp: 00045F5FH << 33 = 0008BEBEH

Is it personal ?

My environment :
WinXP SP2 + Cygwin 2.510.2.2

Regards.

-L.Guo

 

[Ian Collins]

I met one problem of shift a number with equal or more than 32 bits.

When running this :

uint32_t num = 0x45F5F;
int shift = 33;
uint32_t res = num << shift;

printf( "\\> exp: %08XH << %d = %08XH\n", num, shift, res );

It shows :

\> exp: 00045F5FH << 33 = 0008BEBEH

What did you expect?

 

[L.G]

What did you expect?

Commonly, left shift one bit should fill a zero at the lowest bit.

So, if I shift left some more bits, why not fill corresponding zeros ?

-L.G

 

[Ian Collins]

Please don't quote signatures.

Commonly, left shift one bit should fill a zero at the lowest bit.

So, if I shift left some more bits, why not fill corresponding zeros ?

Typical shifters on 32 bit machines use modulo 32, so a shift of 33 bits
is equivalent to a shift of 1 bit.

 

[Keith Thompson]

I met one problem of shift a number with equal or more than 32 bits.

When running this :

uint32_t num = 0x45F5F;
int shift = 33;
uint32_t res = num << shift;

printf( "\\> exp: %08XH << %d = %08XH\n", num, shift, res );

It shows :

\> exp: 00045F5FH << 33 = 0008BEBEH

Is it personal ?

Personal? I have no idea what you mean by that, but ...

The definition of the shift operators says in part (C99 6.5.7p3):

The integer promotions are performed on each of the operands. The
type of the result is that of the promoted left operand. If the
value of the right operand is negative or is greater than or equal
to the width of the promoted left operand, the behavior is
undefined.

So don't do that.

Practically speaking, different CPUs behave differently for operations
like this. Leaving such cases undefined allows the common case
(0 <= bits < WIDTH) to be implemented straightforwardly without having
to emit extra code to handle other cases.

 

[L.G]

The definition of the shift operators says in part (C99 6.5.7p3):

The integer promotions are performed on each of the operands. The
type of the result is that of the promoted left operand. If the
value of the right operand is negative or is greater than or equal
to the width of the promoted left operand, the behavior is
undefined.

So don't do that.

Practically speaking, different CPUs behave differently for operations
like this. Leaving such cases undefined allows the common case
(0 <= bits < WIDTH) to be implemented straightforwardly without having
to emit extra code to handle other cases.

Thank you.

I'll follow this in my future work.

 

[Kenneth Brody]

I met one problem of shift a number with equal or more than 32 bits.

When running this :

uint32_t num = 0x45F5F;
int shift = 33;
uint32_t res = num << shift;

printf( "\\> exp: %08XH << %d = %08XH\n", num, shift, res );

It shows :

\> exp: 00045F5FH << 33 = 0008BEBEH

Is it personal ?

My environment :
WinXP SP2 + Cygwin 2.510.2.2

My understanding is that shifting by more that the width of the
item is either "implementation defined" or UB. In this case,
you are asking to shift a 32-bit integer by 33 bits.

My guess, based on experience with x86 hardware, is that the CPU
only uses the low-order 5 bits of the shift value (2^5 == 32),
so a shift of 33 (0x21) is treated the same as a shift of 1
(0x21 & 0x1f == 0x01).

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>