# Left Shift problem

• 10-11-2001
Mox
Left Shift problem
Hi!

I have a question about left shifting (<<). What happens to the left most bit? Does it disappears or does it go to the right most bit?
And is there a way to influence this?

I ask this because I didn't get the desired results in the following code. It is (or should be) code to calculate the RGB value of white for a given RGBBitCount:

unsigned long RGBValue = (1 << RGBBitCount) - 1;

RGBBitCount is also a unsigned long and either 16, 24 or 32 (in most normal cases).
But when it is 32, 1 << 32 = 1, where it should be 0. So the left most bit goes to the right most one. But that's not what I want and expect... because RGBValue will become 0 in that case, where it should be -1 (or 2^32 - 1 but I don't know exactly what that is ;))

Is there a way to solve this?
Thanks!

Joren
• 10-11-2001
swoopy
My computer gives -1. I did:

unsigned long a = 1;
//signed long a = 0xffffffff;
unsigned long b;
b = (a << 32) - 1;
printf("b:%lx\n",b);
printf("b:%ld\n",b);
• 10-12-2001
Mox
My computer still gives 0.

Maybe it's the compiler? I use VC++ 6...
Or the processor? I have a AMD Athlon...

Is there some way to fix this???

Joren
• 10-12-2001
Mox
I tried some more thins and this is what I found out:

(a and b are unsigned long)

b = (1 << a) - 1;//a = 32
->gives b = 0

b = (a << 32) - 1;//a = 1
->gives b=0

but

b = (1 << 32) - 1;
->gives b = -1

in the last case, it doesn't matter if I cast the values to unsigned long or not (don't know if it should matter but I'll just mention it anyway :))

What is going on here???
Can anybody help me?

Joren
• 10-12-2001
swoopy
Quote:

Originally posted by Mox
b = (1 << a) - 1;//a = 32
->gives b = 0
I also get 0 for this one. I'm not sure why 0. To fix this:

b = (1L << a) - 1;//a = 32
or
b = (1L << a) - 1;//a = 32

The other expression may work using:

b = (a << 32L) - 1;//a = 1
• 10-12-2001
oskilian
well, I don't know what's going on with your code, but left-shifting erases the last bit (or it doesn't mind it)
if you shift it 32 bits in a 32 byte variable, of course you will get 0 because of this:

Code:

```bit count: 33 32 31 30 29 . . . 5 4 3 2 1 bit value: 0  0  0  0  0  . . . 0 0 0 0 1 bit after: 1  0  0  0  0  . . . 0 0 0 0 0```
so the bit is shifted 32 positions, from position 1 to 33 (of course, 1+32=33), but the variable only minds the first 32 bits, so you get 0.

when you do
a = 1 << 32;
it could do the thing above, or move the bit to position 32 (it depends on the compiler)

Oskilian
• 10-12-2001
TerranFury
There's a command in x86 ASM to do the wrap-around shifting, but I forget what it is...
• 10-13-2001
Mox
Hum, my reply has been removed (or never posted), but I'll try again...

Quote:

b = (1L << a) - 1;//a = 32
or
b = (1L << a) - 1;//a = 32
this still doesn't work

Here's my assembly code (made by my compiler, I don't know assembly myself), maybe you can see the problem here...

Code:

```12:      unsigned long a = 32; 00401068  mov        dword ptr [ebp-4],20h 13:      //signed long a = 0xffffffff; 14:      unsigned long b; 15:      b = ((long)2 << (long)a); 0040106F  mov        eax,2 00401074  mov        ecx,dword ptr [ebp-4] 00401077  shl        eax,cl 00401079  mov        dword ptr [ebp-8],eax```
Maybe the the compiler checks to see if the right operand of lshift is % 32 before it executes because if I do: 2 << a (with a = 32) it also gives 2 (instead of 0)

Joren