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

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);

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???
Please help!

Joren

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

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

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

There's a command in x86 ASM to do the wrap-around shifting, but I forget what it is...

Hum, my reply has been removed (or never posted), but I'll try again...

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