What are bitwise shift (bit-shift) operators and how do they work?

Question

I've been attempting to learn C in my spare time, and other languages (C#, Java, etc.) have the same concept (and often the same operators)...

At a core level, what does bit-shifting (<<, >>, >>>) do, what problems can it help solve, and what gotchas lurk around the bend? In other words, an absolute beginner's guide to bit shifting in all its goodness.

Subfamily

The functional or non-functional cases in which you would use bitshifting in 3GL's are few. – Hupp

After reading these answers you may want to look at these links: graphics.stanford.edu/~seander/bithacks.html & jjj.de/bitwizardry/bitwizardrypage.html – Rancourt

It's important to note that bit-shifting is extremely easy and fast for computers to do. By finding ways to use bit-shifting in you program, you can greatly reduce memory usage and execution times. – Spectrogram

Answer 1

The bit shifting operators do exactly what their name implies. They shift bits. Here's a brief (or not-so-brief) introduction to the different shift operators.

The Operators

• >> is the arithmetic (or signed) right shift operator.
• >>> is the logical (or unsigned) right shift operator.
• << is the left shift operator, and meets the needs of both logical and arithmetic shifts.

All of these operators can be applied to integer values (int, long, possibly short and byte or char). In some languages, applying the shift operators to any datatype smaller than int automatically resizes the operand to be an int.

Note that <<< is not an operator, because it would be redundant.

Also note that C and C++ do not distinguish between the right shift operators. They provide only the >> operator, and the right-shifting behavior is implementation defined for signed types. The rest of the answer uses the C# / Java operators.

(In all mainstream C and C++ implementations including GCC and Clang/LLVM, >> on signed types is arithmetic. Some code assumes this, but it isn't something the standard guarantees. It's not undefined, though; the standard requires implementations to define it one way or another. However, left shifts of negative signed numbers is undefined behaviour (signed integer overflow). So unless you need arithmetic right shift, it's usually a good idea to do your bit-shifting with unsigned types.)

---

Left shift (<<)

Integers are stored, in memory, as a series of bits. For example, the number 6 stored as a 32-bit int would be:

00000000 00000000 00000000 00000110

Shifting this bit pattern to the left one position (6 << 1) would result in the number 12:

00000000 00000000 00000000 00001100

As you can see, the digits have shifted to the left by one position, and the last digit on the right is filled with a zero. You might also note that shifting left is equivalent to multiplication by powers of 2. So 6 << 1 is equivalent to 6 * 2, and 6 << 3 is equivalent to 6 * 8. A good optimizing compiler will replace multiplications with shifts when possible.

Non-circular shifting

Please note that these are not circular shifts. Shifting this value to the left by one position (3,758,096,384 << 1):

11100000 00000000 00000000 00000000

results in 3,221,225,472:

11000000 00000000 00000000 00000000

The digit that gets shifted "off the end" is lost. It does not wrap around.

---

Logical right shift (>>>)

A logical right shift is the converse to the left shift. Rather than moving bits to the left, they simply move to the right. For example, shifting the number 12:

00000000 00000000 00000000 00001100

to the right by one position (12 >>> 1) will get back our original 6:

00000000 00000000 00000000 00000110

So we see that shifting to the right is equivalent to division by powers of 2.

Lost bits are gone

However, a shift cannot reclaim "lost" bits. For example, if we shift this pattern:

00111000 00000000 00000000 00000110

to the left 4 positions (939,524,102 << 4), we get 2,147,483,744:

10000000 00000000 00000000 01100000

and then shifting back ((939,524,102 << 4) >>> 4) we get 134,217,734:

00001000 00000000 00000000 00000110

We cannot get back our original value once we have lost bits.

---

Arithmetic right shift (>>)

The arithmetic right shift is exactly like the logical right shift, except instead of padding with zero, it pads with the most significant bit. This is because the most significant bit is the sign bit, or the bit that distinguishes positive and negative numbers. By padding with the most significant bit, the arithmetic right shift is sign-preserving.

For example, if we interpret this bit pattern as a negative number:

10000000 00000000 00000000 01100000

we have the number -2,147,483,552. Shifting this to the right 4 positions with the arithmetic shift (-2,147,483,552 >> 4) would give us:

11111000 00000000 00000000 00000110

or the number -134,217,722.

So we see that we have preserved the sign of our negative numbers by using the arithmetic right shift, rather than the logical right shift. And once again, we see that we are performing division by powers of 2.

Norry

>> and >>> are equivalent in C, which he is probably used too. – Doubleminded

The answer should make it more clear that this a Java-specific answer. There is no >>> operator in C/C++ or C#, and whether or not >> propagates the sign is implementation defined in C/C++ (a major potential gotcha) – Melodie

The answer is totally incorrect in the context of C language. There's no meaningful division into "arithmetic" and "logical" shifts in C. In C the shifts work as expected on unsigned values and on positive signed values - they just shift bits. On negative values, right-shift is implementation defined (i.e. nothing can be said about what it does in general), and left-shift is simply prohibited - it produces undefined behavior. – Midas

Michael, this is addressed in the answer: Also note that C and C++ do not distinguish between the right shift operators. They provide only the >> operator, and the shifting behavior is implementation defined. – Norry

Audrey, there is certainly a difference between arithmetic and logical right shifting. C simply leaves the choice implementation defined. And left shift on negative values is definitely not prohibited. Shift 0xff000000 to the left one bit and you'll get 0xfe000000. – Norry

@DerekPark suppose I multiple a big negative number by 2 . In that case left shift would cause us to loose the signed bit which is was the most siginificant bit . How do we get back the sign after this because obviously the answer has to be negative ? – Olecranon

@Geek, if you multiply a large enough negative number, you'll underflow and end up with a positive number. You'll get the same effect if you shift. e.g. with 32-bit signed integers, -2000000000 << 1 == -2000000000 * 2 == 294967296. You can't "get back" the sign bit, because the answer is not negative. Integral arithmetic is modular in C, Java, and similar languages. – Norry

A good optimizing compiler will substitute shifts for multiplications when possible. What? Bitshifts are orders of magnitude faster when it comes down to the low level operations of a CPU, a good optimizing compiler would do the exact opposite, that is, turning ordinary multiplications by powers of two into bit shifts. – Photoneutron

Well, I wanna know that why bit-shifting is not applicable for double and float data types. Any help please? – Herbartian

@Mahn, you're reading it backwards from my intent. Substitute Y for X means to replace X with Y. Y is the substitute for X. So the shift is the substitute for the multiplication. – Norry

@ambigram_maker, in a sense, bit shifting is not even applicable to integers, because it operates on bit fields, a lower level of abstraction. C-style languages generally overload the integral types to represent both whole numbers and bit fields, but this is basically historical coincidence. Shifts could be defined for floating-point types, but the effect would be equivalent to casting to an integer type of the same size, shifting, and casting back to the floating point type. This would result in junk most of the time, though, whereas a shift on an integer happens to produce a useful result. – Norry

In C/C++, left-shifting of negative values (or left-shifting "into the sign bit") is not allowed. From the C99 standard, §6.5.7.4 (given the expression "E1 << E2"): "If E1 has a signed type and nonnegative value, and E1 * 2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined." As always with "undefined" behavior, it may work one moment and crash the next. – Viceregal

@DerekPark "A good optimizing compiler will substitute shifts for multiplications when possible." He got 3 UPs and you got one which could suggest that pretty decent amount of people could misunderstood. Why not edit it using simpler English since not all here are native in English? – Acre

@SørenLøvborg that's pretty surprising - the amount of code which assumes that 'and nonnegative value' isn't in that phrase is huge. And machines where it won't work are virtually all in museums. But there it is. I would have thought it would be 'implementation defined'. To avoid this issue, one can write n<<3 as n*8, and n<<k as n*(1<<k). Have just checked that gcc and clang treat that the same as n<<k. There may well be compilers that leave the multiply in, though. – Underworld

@greggo: Doesn't entirely solve the problem, since signed integer overflow is also undefined behavior. :-) But yes, as a rule, bit operators are best reserved for unsigned integers. And remember, undefined behavior is not as much about "what the CPU would do", as it's about the optimizer doing surprising things to your code. For instance, if you write y = x << 3; if (x < 0) {...}, the C standard says that the compiler may rightfully leave out the entire if block... because you just promised it that x is guaranteed to be non-negative! – Viceregal

@SørenLøvborg Interesting. So, a compiler which does adds and subtracts and shifts etc as per '2's complement' convention (left shift and add/sub and multiply being bitwise equivalent to the corresponding unsigned ops) - and which considers this, even with overflow, as defined behaviour wrt the kind of optimization you mention -- is actually providing a language extension. One which I believe all major compilers supply, and which would be troublesome to retract. But I can see why the standards group would want to leave this outside the spec. – Underworld

@Underworld I just tested GCC 4.8 and Clang 3.4, and neither optimized out the block in my example, but the list of people being bitten by signed integer overflow optimizations is long. C compilers generally go beyond the C standard, though, mostly to avoid complaints from people who, perhaps, had too much faith in internet posts like this answer, which remains blatantly wrong for C/C++. (You can enable -fwrapv if you really must have well-defined signed overflows, but you're no longer writing standard C.) – Viceregal

If this is indeed specific to Java like @MichaelBurr points out can a mod or someone edit this? It is the very first thing that pops up in Google when you search for bit shifting. – Containerize

I don't understand why <<< would be redundant, since << would supposedly push out the sign bit. – Diaphysis

@timur: it's because of how representation of negative numbers works. For the higher (i.e. closer to 0) half of the negative numbers the second bit is 1 (so shifting all bits like in logical shift keeps the number negative, no need for a special action), and for the other half the shift results in an underflow anyway, so breaking the sign bit doesn't really matter. – Unknown

Isn't there a typo? 11100000 00000000 00000000 00000000 shifted to left by 1 results in 00000001 11000000 00000000 00000000 00000000. You can' get 3,221,225,472 by multiplying 3,758,096,384 by 2! But 7,516,192,768. – Roar

This answer is not specific to Java. It is specific to Computer Science, which has very clear definitions of Logical and Arithmetic shifts. The fact, that C standard is loose about it and compiler developers do what they feel, doesn't mean that every author has to specify that. – Buckden

Answer 2

Let's say we have a single byte:

0110110

Applying a single left bitshift gets us:

1101100

The leftmost zero was shifted out of the byte, and a new zero was appended to the right end of the byte.

The bits don't rollover; they are discarded. That means if you left shift 1101100 and then right shift it, you won't get the same result back.

Shifting left by N is equivalent to multiplying by 2^N.

Shifting right by N is (if you are using ones' complement) is the equivalent of dividing by 2^N and rounding to zero.

Bitshifting can be used for insanely fast multiplication and division, provided you are working with a power of 2. Almost all low-level graphics routines use bitshifting.

For example, way back in the olden days, we used mode 13h (320x200 256 colors) for games. In Mode 13h, the video memory was laid out sequentially per pixel. That meant to calculate the location for a pixel, you would use the following math:

memoryOffset = (row * 320) + column

Now, back in that day and age, speed was critical, so we would use bitshifts to do this operation.

However, 320 is not a power of two, so to get around this we have to find out what is a power of two that added together makes 320:

(row * 320) = (row * 256) + (row * 64)

Now we can convert that into left shifts:

(row * 320) = (row << 8) + (row << 6)

For a final result of:

memoryOffset = ((row << 8) + (row << 6)) + column

Now we get the same offset as before, except instead of an expensive multiplication operation, we use the two bitshifts...in x86 it would be something like this (note, it's been forever since I've done assembly (editor's note: corrected a couple mistakes and added a 32-bit example)):

mov ax, 320; 2 cycles
mul word [row]; 22 CPU Cycles
mov di,ax; 2 cycles
add di, [column]; 2 cycles
; di = [row]*320 + [column]

; 16-bit addressing mode limitations:
; [di] is a valid addressing mode, but [ax] isn't, otherwise we could skip the last mov

Total: 28 cycles on whatever ancient CPU had these timings.

Vrs

mov ax, [row]; 2 cycles
mov di, ax; 2
shl ax, 6;  2
shl di, 8;  2
add di, ax; 2    (320 = 256+64)
add di, [column]; 2
; di = [row]*(256+64) + [column]

12 cycles on the same ancient CPU.

Yes, we would work this hard to shave off 16 CPU cycles.

In 32 or 64-bit mode, both versions get a lot shorter and faster. Modern out-of-order execution CPUs like Intel Skylake (see http://agner.org/optimize/) have very fast hardware multiply (low latency and high throughput), so the gain is much smaller. AMD Bulldozer-family is a bit slower, especially for 64-bit multiply. On Intel CPUs, and AMD Ryzen, two shifts are slightly lower latency but more instructions than a multiply (which may lead to lower throughput):

imul edi, [row], 320    ; 3 cycle latency from [row] being ready
add  edi, [column]      ; 1 cycle latency (from [column] and edi being ready).
; edi = [row]*(256+64) + [column],  in 4 cycles from [row] being ready.

vs.

mov edi, [row]
shl edi, 6               ; row*64.   1 cycle latency
lea edi, [edi + edi*4]   ; row*(64 + 64*4).  1 cycle latency
add edi, [column]        ; 1 cycle latency from edi and [column] both being ready
; edi = [row]*(256+64) + [column],  in 3 cycles from [row] being ready.

Compilers will do this for you: See how GCC, Clang, and Microsoft Visual C++ all use shift+lea when optimizing return 320*row + col;.

The most interesting thing to note here is that x86 has a shift-and-add instruction (LEA) that can do small left shifts and add at the same time, with the performance as an add instruction. ARM is even more powerful: one operand of any instruction can be left or right shifted for free. So scaling by a compile-time-constant that's known to be a power-of-2 can be even more efficient than a multiply.

---

OK, back in the modern days... something more useful now would be to use bitshifting to store two 8-bit values in a 16-bit integer. For example, in C#:

// Byte1: 11110000
// Byte2: 00001111

Int16 value = ((byte)(Byte1 >> 8) | Byte2));

// value = 000011111110000;

In C++, compilers should do this for you if you used a struct with two 8-bit members, but in practice they don't always.

Doubleminded

Expanding this, on Intel processors (and a lot of others) it's faster to do this: int c, d; c=d<<2; Than this: c=4*d; Sometimes, even "c=d<<2 + d<<1" is faster than "c=6*d"!! I used these tricks extensively for graphic functions in the DOS era, I don't think they're so useful anymore... – Here

@Joe: If these tricks aren't useful anymore, does that mean that compiler writers are using them now? – Offend

@James: not quite, nowadays it's rather the video-card's firmware which includes code like that, to be executed by the GPU rather than the CPU. So theoretically you don't need to implement code like this (or like Carmack's black-magic inverse root function) for graphic functions :-) – Here

@JoePineda @james The compiler writers are definitely using them. If you write c=4*d you will get a shift. If you write k = (n<0) that may be done with shifts too: k = (n>>31)&1 to avoid a branch. Bottom line, this improvement in cleverness of compilers means it's now unnecessary to use these tricks in the C code, and they compromise readability and portability. Still very good to know them if you're writing e.g. SSE vector code; or any situation where you need it fast and there's a trick which the compiler isn't using (e.g. GPU code). – Underworld

Another good example: very common thing is if(x >= 1 && x <= 9) which can be done as if( (unsigned)(x-1) <=(unsigned)(9-1)) Changing two conditional tests to one can be a big speed advantage; especially when it allows predicated execution instead of branches. I used this for years (where justified) until I noticed abt 10 years ago that compilers had started doing this transform in the optimizer, then I stopped. Still good to know, since there are similar situations where the compiler can't make the transform for you. Or if you're working on a compiler. – Underworld

Is there a reason that your "byte" is only 7 bits? – Wilfredwilfreda

Answer 3

Bitwise operations, including bit shift, are fundamental to low-level hardware or embedded programming. If you read a specification for a device or even some binary file formats, you will see bytes, words, and dwords, broken up into non-byte aligned bitfields, which contain various values of interest. Accessing these bit-fields for reading/writing is the most common usage.

A simple real example in graphics programming is that a 16-bit pixel is represented as follows:

  bit | 15| 14| 13| 12| 11| 10| 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1  | 0 |
      |       Blue        |         Green         |       Red          |

To get at the green value you would do this:

 #define GREEN_MASK  0x7E0
 #define GREEN_OFFSET  5

 // Read green
 uint16_t green = (pixel & GREEN_MASK) >> GREEN_OFFSET;

Explanation

In order to obtain the value of green ONLY, which starts at offset 5 and ends at 10 (i.e. 6-bits long), you need to use a (bit) mask, which when applied against the entire 16-bit pixel, will yield only the bits we are interested in.

#define GREEN_MASK  0x7E0

The appropriate mask is 0x7E0 which in binary is 0000011111100000 (which is 2016 in decimal).

uint16_t green = (pixel & GREEN_MASK) ...;

To apply a mask, you use the AND operator (&).

uint16_t green = (pixel & GREEN_MASK) >> GREEN_OFFSET;

After applying the mask, you'll end up with a 16-bit number which is really just a 11-bit number since its MSB is in the 11th bit. Green is actually only 6-bits long, so we need to scale it down using a right shift (11 - 6 = 5), hence the use of 5 as offset (#define GREEN_OFFSET 5).

Also common is using bit shifts for fast multiplication and division by powers of 2:

 i <<= x;  // i *= 2^x;
 i >>= y;  // i /= 2^y;

Gerbold

0x7e0 is the same as 11111100000 which is 2016 in decimal. – Charlena

Answer 4

Bit Masking & Shifting

Bit shifting is often used in low-level graphics programming. For example, a given pixel color value encoded in a 32-bit word.

 Pixel-Color Value in Hex:    B9B9B900
 Pixel-Color Value in Binary: 10111001  10111001  10111001  00000000

For better understanding, the same binary value labeled with what sections represent what color part.

                                 Red     Green     Blue       Alpha
 Pixel-Color Value in Binary: 10111001  10111001  10111001  00000000

Let's say for example we want to get the green value of this pixel's color. We can easily get that value by masking and shifting.

Our mask:

                  Red      Green      Blue      Alpha
 color :        10111001  10111001  10111001  00000000
 green_mask  :  00000000  11111111  00000000  00000000

 masked_color = color & green_mask

 masked_color:  00000000  10111001  00000000  00000000

The logical & operator ensures that only the values where the mask is 1 are kept. The last thing we now have to do, is to get the correct integer value by shifting all those bits to the right by 16 places (logical right shift).

 green_value = masked_color >>> 16

Et voilà, we have the integer representing the amount of green in the pixel's color:

 Pixels-Green Value in Hex:     000000B9
 Pixels-Green Value in Binary:  00000000 00000000 00000000 10111001
 Pixels-Green Value in Decimal: 185

This is often used for encoding or decoding image formats like jpg, png, etc.

Dimercaprol

Isn't it easier to cast your original, say 32bit cl_uint, as something like cl_uchar4 and access the byte you want directly as *.s2? – Mascarenas

Answer 5

One gotcha is that the following is implementation dependent (according to the ANSI standard):

char x = -1;
x >> 1;

x can now be 127 (01111111) or still -1 (11111111).

In practice, it's usually the latter.

Condominium

If I recall it correctly, the ANSI C standard explicitly says this is implementation-dependent, so you need to check your compiler's documentation to see how it's implemented if you want to right-shift signed integers on your code. – Here

Yes, I just wanted to emphasize the ANSI standard itself says so, it's not a case where vendors are simply not following the standard or that the standard says nothing about this particualr case. – Here

Answer 6

I am writing tips and tricks only. It may be useful in tests and exams.

1. n = n*2: n = n<<1
2. n = n/2: n = n>>1
3. Checking if n is power of 2 (1,2,4,8,...): check !(n & (n-1))
4. Getting x^th bit of n: n |= (1 << x)
5. Checking if x is even or odd: x&1 == 0 (even)
6. Toggle the n^th bit of x: x ^ (1<<n)

Hummock

Are x and n 0 indexed? – Transmundane

Ad 5.: What if it is a negative number? – Strop

so, can we conclude 2 in binary is like 10 in decimal? and bit shifting is like adding or substracting one more number behind another number in decimal ? – Gel

For shortcut (3) an input of 0 will result in true, so be sure to check for that input. – Encephalogram

For item 4. you need the bitwise & operator, n &= (1 << x) to get just the single bit at position x. – Sundowner

Answer 7

Note that in the Java implementation, the number of bits to shift is mod'd by the size of the source.

For example:

(long) 4 >> 65

equals 2. You might expect shifting the bits to the right 65 times would zero everything out, but it's actually the equivalent of:

(long) 4 >> (65 % 64)

This is true for <<, >>, and >>>. I have not tried it out in other languages.

Jefferey

Huh, interesting! In C, this is technically undefined behavior. gcc 5.4.0 gives a warning, but gives 2 for 5 >> 65; as well. – Metacarpus

Answer 8

The Bitwise operators are used to perform operations a bit-level or to manipulate bits in different ways. The bitwise operations are found to be much faster and are some times used to improve the efficiency of a program. Basically, Bitwise operators can be applied to the integer types: long, int, short, char and byte.

Bitwise Shift Operators

They are classified into two categories left shift and the right shift.

• Left Shift(<<): The left shift operator, shifts all of the bits in value to the left a specified number of times. Syntax: value << num. Here num specifies the number of position to left-shift the value in value. That is, the << moves all of the bits in the specified value to the left by the number of bit positions specified by num. For each shift left, the high-order bit is shifted out (and ignored/lost), and a zero is brought in on the right. This means that when a left shift is applied to 32-bit compiler, bits are lost once they are shifted past bit position 31. If the compiler is of 64-bit then bits are lost after bit position 63.

Output: 6, Here the binary representation of 3 is 0...0011(considering 32-bit system) so when it shifted one time the leading zero is ignored/lost and all the rest 31 bits shifted to left. And zero is added at the end. So it became 0...0110, the decimal representation of this number is 6.

• In the case of a negative number:

Output: -2, In java negative number, is represented by 2's complement. SO, -1 represent by 2^32-1 which is equivalent to 1....11(Considering 32-bit system). When shifted one time the leading bit is ignored/lost and the rest 31 bits shifted to left and zero is added at the last. So it becomes, 11...10 and its decimal equivalent is -2. So, I think you get enough knowledge about the left shift and how its work.

• Right Shift(>>): The right shift operator, shifts all of the bits in value to the right a specified of times. Syntax: value >> num, num specifies the number of positions to right-shift the value in value. That is, the >> moves/shift all of the bits in the specified value of the right the number of bit positions specified by num. The following code fragment shifts the value 35 to the right by two positions:

Output: 8, As a binary representation of 35 in a 32-bit system is 00...00100011, so when we right shift it two times the first 30 leading bits are moved/shifts to the right side and the two low-order bits are lost/ignored and two zeros are added at the leading bits. So, it becomes 00....00001000, the decimal equivalent of this binary representation is 8. Or there is a simple mathematical trick to find out the output of this following code: To generalize this we can say that, x >> y = floor(x/pow(2,y)). Consider the above example, x=35 and y=2 so, 35/2^2 = 8.75 and if we take the floor value then the answer is 8.

Output:

But remember one thing this trick is fine for small values of y if you take the large values of y it gives you incorrect output.

• In the case of a negative number: Because of the negative numbers the Right shift operator works in two modes signed and unsigned. In signed right shift operator (>>), In case of a positive number, it fills the leading bits with 0. And In case of a negative number, it fills leading bits with 1. To keep the sign. This is called 'sign extension'.

Output: -5, As I explained above the compiler stores the negative value as 2's complement. So, -10 is represented as 2^32-10 and in binary representation considering 32-bit system 11....0110. When we shift/ move one time the first 31 leading bits got shifted in the right side and the low-order bit got lost/ignored. So, it becomes 11...0011 and the decimal representation of this number is -5 (How I know the sign of number? because the leading bit is 1). It is interesting to note that if you shift -1 right, the result always remains -1 since sign extension keeps bringing in more ones in the high-order bits.

• Unsigned Right Shift(>>>): This operator also shifts bits to the right. The difference between signed and unsigned is the latter fills the leading bits with 1 if the number is negative and the former fills zero in either case. Now the question arises why we need unsigned right operation if we get the desired output by signed right shift operator. Understand this with an example, If you are shifting something that does not represent a numeric value, you may not want sign extension to take place. This situation is common when you are working with pixel-based values and graphics. In these cases, you will generally want to shift a zero into the high-order bit no matter what it's the initial value was.

Output: 2147483647, Because -2 is represented as 11...10 in a 32-bit system. When we shift the bit by one, the first 31 leading bit is moved/shifts in right and the low-order bit is lost/ignored and the zero is added to the leading bit. So, it becomes 011...1111 (2^31-1) and its decimal equivalent is 2147483647.

Wallack

Please review Why not upload images of code/errors when asking a question? (e.g., "Images should only be used to illustrate problems that can't be made clear in any other way, such as to provide screenshots of a user interface.") and do the right thing (it covers answers as well). Thanks in advance. – Strop

Answer 9

Some useful bit operations/manipulations in Python.

I implemented Ravi Prakash's answer in Python.

# Basic bit operations
# Integer to binary
print(bin(10))

# Binary to integer
print(int('1010', 2))

# Multiplying x with 2 .... x**2 == x << 1
print(200 << 1)

# Dividing x with 2 .... x/2 == x >> 1
print(200 >> 1)

# Modulo x with 2 .... x % 2 == x & 1
if 20 & 1 == 0:
    print("20 is a even number")

# Check if n is power of 2: check !(n & (n-1))
print(not(33 & (33-1)))

# Getting xth bit of n: (n >> x) & 1
print((10 >> 2) & 1) # Bin of 10 == 1010 and second bit is 0

# Toggle nth bit of x : x^(1 << n)
# take bin(10) == 1010 and toggling second bit in bin(10) we get 1110 === bin(14)
print(10^(1 << 2))

Skippy

Answer 10

Hopefully some find this decimal-to-binary-string visualizer I made to be helpful in understanding how bit manipulation operators relate to base conversion via arithmetic :

Feeding in any unsigned int up to 2^53 - 1, it would generate both

1. The algebraic version of the binary string, which can be directly fed into bc, Wolfram Alpha, most likely Excel too (haven't tested it), as well as

2. The purely bit manipulation version that's simply a series of bitwise OR paired with bit-shifts, which can be directly fed into C/Perl codes.

-- Note : in the algebraic one, the binary string is shown in big-endian MSB first notation, while the bit-shifting one is in little-endian LSB first.

-- Note : for visual clarity purposes, zeros have been blanked out.

---

function rev(__,_,___) {

    (_ = length(__ = (___ = _ = "")__)) % length("__") &&
   ___ = substr(__, _--)

   do ___ = ___ substr(__,_,
         _>--_) substr(__,_,_>--_)
   while(_)

   return ___
}

function dec2bin_visualizer(__,_) {

    return length(__ = (_ = "")__) <= ++_*_++ &&
                      (__ = __+!_) <= _ \
    ? (__)"\n"(__<_-- ? __ : (_)"<<"(_)) : \
    (__ = (_ = index(__ = sprintf(\
         (_=(_ =   "2*(" )(_ = (_)_ (_)_) (_)_)_ (_)_ \
         (_=(_ = "%+1.d)")(_ = (_)_ (_)_) (_)_)_ (_)_ "%+.d",
    _ = int(__/= (_ += ++_)^(_^_^_+(_+_+_)^_)),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),_ = int(__+=__-=_),_ = int(__+=__-=_),
    _ = int(__+=__-=_),
    _ = int(__+=__-=_)), "(+")) \
    ? substr(__,!!_,_++) substr(__,++_) \
    : substr((__)"", (__ = substr(__, index(__, ++_)))^!_,
      (_ + ++_) * gsub("[)]", "&", __))__) "\n" \
    substr(_ = "", (__ = rev(__))^_,
                   -gsub("[(][*][2]",
     _ = "_", __) * gsub("[)]",
         "(", __) * gsub(_,
      ")<<1", __) * gsub("1[+]",
        "1|", __) * gsub(" +",_ = "", __)) ("\n")__
 }

---

 1  57885161
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1)+1) )+1)+1)+1) ) )+1)+1) )+1) ) ) ) ) )+1)+1)+1)+1) )+1) ) )+1
    1|(((1|((1|(1|(1|(1|((((((1|((1|(1|(((1|(1|(1|((1|(1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

 2  43112609
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1) ) )+1) ) ) )+1)+1)+1) )+1)+1) ) ) )+1) )+1) ) ) ) )+1
    1|(((((1|((1|((((1|(1|((1|(1|(1|((((1|(((1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

 3  42643801
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1) ) ) )+1) )+1) )+1) )+1)+1) ) ) )+1) )+1) )+1)+1) ) )+1
    1|(((1|(1|((1|((1|((((1|(1|((1|((1|((1|((((1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

 4  37156667
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) ) )+1)+1) )+1)+1) )+1)+1)+1)+1) )+1)+1)+1) ) )+1)+1)+1) )+1)+1
    1|(1|((1|(1|(1|(((1|(1|(1|((1|(1|(1|(1|((1|(1|((1|(1|((((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

 5  32582657
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1)+1)+1)+1)+1) ) ) )+1) ) )+1) )+1)+1) ) ) ) ) ) ) ) ) )+1
    1|((((((((((1|(1|((1|(((1|((((1|(1|(1|(1|(1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

 6  30402457
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1)+1)+1) ) )+1)+1)+1)+1)+1)+1)+1) ) )+1)+1)+1)+1) ) )+1)+1) ) )+1
    1|(((1|(1|(((1|(1|(1|(1|(((1|(1|(1|(1|(1|(1|(1|(((1|(1|(1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

 7  25964951
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1)+1) ) ) )+1)+1) ) ) ) )+1)+1) ) ) )+1)+1) ) )+1) )+1)+1)+1
    1|(1|(1|((1|(((1|(1|((((1|(1|(((((1|(1|((((1|(1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

 8  24036583
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1)+1) )+1)+1)+1) )+1)+1) ) ) )+1) ) )+1)+1)+1) ) )+1)+1)+1
    1|(1|(1|(((1|(1|(1|(((1|((((1|(1|((1|(1|(1|((1|(1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

 9  20996011
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1) ) ) ) ) ) ) )+1) )+1)+1)+1)+1)+1)+1) )+1) )+1) )+1)+1
    1|(1|((1|((1|((1|(1|(1|(1|(1|(1|((1|((((((((1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

10  13466917
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1)+1) ) )+1)+1) )+1) )+1)+1)+1)+1)+1) )+1) ) )+1) ) )+1) )+1
    1|((1|(((1|(((1|((1|(1|(1|(1|(1|((1|((1|(1|(((1|(1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

11  6972593
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1)+1) )+1) )+1) ) )+1)+1) ) )+1) ) )+1) )+1)+1) ) ) )+1
    1|((((1|(1|((1|(((1|(((1|(1|(((1|((1|((1|(1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

12  3021377
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1)+1)+1) ) ) ) )+1)+1) )+1) ) )+1) ) ) ) ) )+1
    1|((((((1|(((1|((1|(1|(((((1|(1|(1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

13  2976221
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1)+1) )+1) )+1)+1) )+1) ) )+1)+1)+1) )+1)+1)+1) )+1
    1|((1|(1|(1|((1|(1|(1|(((1|((1|(1|((1|((1|(1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

14  1398269
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1) )+1) )+1) )+1) )+1) )+1)+1)+1)+1)+1)+1)+1) )+1
    1|((1|(1|(1|(1|(1|(1|(1|((1|((1|((1|((1|((1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

15  1257787
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) )+1)+1) ) )+1)+1) ) ) )+1) ) )+1)+1)+1) )+1)+1
    1|(1|((1|(1|(1|(((1|((((1|(1|(((1|(1|(((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

16  859433
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1)+1) )+1) ) ) )+1)+1)+1) )+1) ) )+1) )+1) ) )+1
    1|(((1|((1|(((1|((1|(1|(1|((((1|((1|(1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

17  756839
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1)+1)+1) ) ) )+1)+1) ) ) )+1)+1) ) )+1)+1)+1
    1|(1|(1|(((1|(1|((((1|(1|((((1|(1|(1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

18  216091
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1)+1) )+1) ) )+1)+1) ) ) ) ) )+1)+1) )+1)+1
    1|(1|((1|(1|((((((1|(1|(((1|((1|(1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

19  132049
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) ) ) ) ) ) )+1)+1)+1)+1) )+1) ) ) )+1
    1|((((1|((1|(1|(1|(1|((((((((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

20  110503
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1)+1) )+1) )+1)+1)+1)+1)+1) )+1) ) )+1)+1)+1
    1|(1|(1|(((1|((1|(1|(1|(1|(1|((1|((1|(1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

21  86243
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1) )+1) ) ) ) )+1)+1)+1) ) ) )+1)+1
    1|(1|((((1|(1|(1|(((((1|((1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

22  44497
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1) )+1)+1) )+1)+1)+1) )+1) ) ) )+1
    1|((((1|((1|(1|(1|((1|(1|((1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

23  23209
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1)+1) )+1) )+1) )+1) )+1) ) )+1
    1|(((1|((1|((1|((1|((1|(1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

24  21701
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1) )+1) ) )+1)+1) ) ) )+1) )+1
    1|((1|((((1|(1|(((1|((1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

25  19937
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) )+1)+1) )+1)+1)+1)+1) ) ) ) )+1
    1|(((((1|(1|(1|(1|((1|(1|(((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

26  11213
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) )+1) )+1)+1)+1)+1) ) )+1)+1) )+1
    1|((1|(1|(((1|(1|(1|(1|((1|((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

27  9941
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) )+1)+1) )+1)+1) )+1) )+1) )+1
    1|((1|((1|((1|(1|((1|(1|(((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

28  9689
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) )+1) )+1)+1)+1) )+1)+1) ) )+1
    1|(((1|(1|((1|(1|(1|((1|(((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

29  4423
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) ) )+1) )+1) ) ) )+1)+1)+1
    1|(1|(1|((((1|((1|((((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

30  4253
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) ) ) )+1) ) )+1)+1)+1) )+1
    1|((1|(1|(1|(((1|(((((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

31  3217
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1)+1) ) )+1) ) )+1) ) ) )+1
    1|((((1|(((1|(((1|(1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

32  2281
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) ) )+1)+1)+1) )+1) ) )+1
    1|(((1|((1|(1|(1|((((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

33  2203
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) ) )+1) ) )+1)+1) )+1)+1
    1|(1|((1|(1|(((1|((((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

34  1279
    2*(2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) )+1)+1)+1)+1)+1)+1)+1)+1
    1|(1|(1|(1|(1|(1|(1|(1|(((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

35  607
    2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) )+1) )+1)+1)+1)+1)+1
    1|(1|(1|(1|(1|((1|(((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

36  521
    2*(2*(2*(2*(2*(2*(2*(2*(2*(1) ) ) ) ) )+1) ) )+1
    1|(((1|((((((1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1)<<1

37  127
    2*(2*(2*(2*(2*(2*(1)+1)+1)+1)+1)+1)+1
    1|(1|(1|(1|(1|(1|(1)<<1)<<1)<<1)<<1)<<1)<<1

38  107
    2*(2*(2*(2*(2*(2*(1)+1) )+1) )+1)+1
    1|(1|((1|((1|(1)<<1)<<1)<<1)<<1)<<1)<<1

39  89
    2*(2*(2*(2*(2*(2*(1) )+1)+1) ) )+1
    1|(((1|(1|((1)<<1)<<1)<<1)<<1)<<1)<<1

40  61
    2*(2*(2*(2*(2*(1)+1)+1)+1) )+1
    1|((1|(1|(1|(1)<<1)<<1)<<1)<<1)<<1

41  31
    2*(2*(2*(2*(1)+1)+1)+1)+1
    1|(1|(1|(1|(1)<<1)<<1)<<1)<<1

42  19
    2*(2*(2*(2*(1) ) )+1)+1
    1|(1|(((1)<<1)<<1)<<1)<<1

43  17
    2*(2*(2*(2*(1) ) ) )+1
    1|((((1)<<1)<<1)<<1)<<1

44  13
    2*(2*(2*(1)+1) )+1
    1|((1|(1)<<1)<<1)<<1

45  7
    2*(2*(1)+1)+1
    1|(1|(1)<<1)<<1

46  5
    2*(2*(1) )+1
    1|((1)<<1)<<1

47  3
    2*(1)+1
    1|(1)<<1

48  2
    2
    1<<1

Woehick

Answer 11

Be aware of that only 32 bit version of PHP is available on the Windows platform.

Then if you for instance shift << or >> more than by 31 bits, results are unexpectable. Usually the original number instead of zeros will be returned, and it can be a really tricky bug.

Of course if you use 64 bit version of PHP (Unix), you should avoid shifting by more than 63 bits. However, for instance, MySQL uses the 64-bit BIGINT, so there should not be any compatibility problems.

UPDATE: From PHP 7 Windows, PHP builds are finally able to use full 64 bit integers: The size of an integer is platform-dependent, although a maximum value of about two billion is the usual value (that's 32 bits signed). 64-bit platforms usually have a maximum value of about 9E18, except on Windows prior to PHP 7, where it was always 32 bit.

Hally