Bit Twiddling Hacks
Bit Twiddling Hacks
Contents
https://graphics.stanford.edu/~seander/bithacks.html 2/30
10/13/2016 Bit Twiddling Hacks
// or, for one less instruction (but not portable):
sign = v >> (sizeof(int) * CHAR_BIT - 1);
The last expression above evaluates to sign = v >> 31 for 32-bit integers. This is one operation faster than the
obvious way, sign = -(v < 0). This trick works because when signed integers are shifted right, the value of the far left
bit is copied to the other bits. The far left bit is 1 when the value is negative and 0 otherwise; all 1 bits gives -1.
Unfortunately, this behavior is architecture-specic.
On the other hand, if you prefer the result be either -1, 0, or +1, then use:
sign = (v != 0) | -(int)((unsigned int)((int)v) >> (sizeof(int) * CHAR_BIT - 1));
// Or, for more speed but less portability:
sign = (v != 0) | (v >> (sizeof(int) * CHAR_BIT - 1)); // -1, 0, or +1
// Or, for portability, brevity, and (perhaps) speed:
sign = (v > 0) - (v < 0); // -1, 0, or +1
If instead you want to know if something is non-negative, resulting in +1 or else 0, then use:
sign = 1 ^ ((unsigned int)v >> (sizeof(int) * CHAR_BIT - 1)); // if v < 0 then 0, else 1
Caveat: On March 7, 2003, Angus Duggan pointed out that the 1989 ANSI C specication leaves the result of
signed right-shift implementation-dened, so on some systems this hack might not work. For greater portability,
Toby Speight suggested on September 28, 2005 that CHAR_BIT be used here and throughout rather than assuming
bytes were 8 bits long. Angus recommended the more portable versions above, involving casting on March 4, 2006.
Rohit Garg suggested the version for non-negative integers on September 12, 2009.
bool f = ((x ^ y) < 0); // true iff x and y have opposite signs
r = (v + mask) ^ mask;
Patented variation:
r = (v ^ mask) - mask;
Some CPUs don't have an integer absolute value instruction (or the compiler fails to use them). On machines where
branching is expensive, the above expression can be faster than the obvious approach, r = (v < 0) ? -(unsigned)v : v,
even though the number of operations is the same.
On March 7, 2003, Angus Duggan pointed out that the 1989 ANSI C specication leaves the result of signed right-
shift implementation-dened, so on some systems this hack might not work. I've read that ANSI C does not require
values to be represented as two's complement, so it may not work for that reason as well (on a diminishingly small
number of old machines that still use one's complement). On March 14, 2004, Keith H. Duggar sent me the patented
variation above; it is superior to the one I initially came up with, r=(+1|(v>>(sizeof(int)*CHAR_BIT-1)))*v,
https://graphics.stanford.edu/~seander/bithacks.html 3/30
10/13/2016 Bit Twiddling Hacks
because a multiply is not used. Unfortunately, this method has been patented in the USA on June 6, 2000 by
Vladimir Yu Volkonsky and assigned to Sun Microsystems. On August 13, 2006, Yuriy Kaminskiy told me that the
patent is likely invalid because the method was published well before the patent was even led, such as in How to
Optimize for the Pentium Processor by Agner Fog, dated November, 9, 1996. Yuriy also mentioned that this
document was translated to Russian in 1997, which Vladimir could have read. Moreover, the Internet Archive also
has an old link to it. On January 30, 2007, Peter Kankowski shared with me an abs version he discovered that was
inspired by Microsoft's Visual C++ compiler output. It is featured here as the primary solution. On December 6,
2007, Hai Jin complained that the result was signed, so when computing the abs of the most negative value, it was
still negative. On April 15, 2008 Andrew Shapira pointed out that the obvious approach could overow, as it lacked
an (unsigned) cast then; for maximum portability he suggested (v < 0) ? (1 + ((unsigned)(-1-v))) :
(unsigned)v. But citing the ISO C99 spec on July 9, 2008, Vincent Lefvre convinced me to remove it becasue
even on non-2s-complement machines -(unsigned)v will do the right thing. The evaluation of -(unsigned)v rst
converts the negative value of v to an unsigned by adding 2**N, yielding a 2s complement representation of v's
value that I'll call U. Then, U is negated, giving the desired result, -U = 0 - U = 2**N - U = 2**N - (v+2**N) = -v =
abs(v).
Compute the minimum (min) or maximum (max) of two integers without branching
int x; // we want to find the minimum of x and y
int y;
int r; // the result goes here
On some rare machines where branching is very expensive and no condition move instructions exist, the above
expression might be faster than the obvious approach, r = (x < y) ? x : y, even though it involves two more
instructions. (Typically, the obvious approach is best, though.) It works because if x<y, then -(x<y) will be all
ones, so r= y ^ (x ^ y) & ~0 = y ^ x ^ y = x. Otherwise, if x>=y, then -(x<y) will be all zeros, so r= y ^ ((x ^ y) &
0) = y. On some machines, evaluating (x < y) as 0 or 1 requires a branch instruction, so there may be no advantage.
If you know that INT_MIN <= x - y <= INT_MAX, then you can use the following, which are faster because (x - y)
only needs to be evaluated once.
r = y + ((x - y) & ((x - y) >> (sizeof(int) * CHAR_BIT - 1))); // min(x, y)
r = x - ((x - y) & ((x - y) >> (sizeof(int) * CHAR_BIT - 1))); // max(x, y)
Note that the 1989 ANSI C specication doesn't specify the result of signed right-shift, so these aren't portable. If
exceptions are thrown on overows, then the values of x and y should be unsigned or cast to unsigned for the
subtractions to avoid unnecessarily throwing an exception, however the right-shift needs a signed operand to
produce all one bits when negative, so cast to signed there.
On March 7, 2003, Angus Duggan pointed out the right-shift portability issue. On May 3, 2005, Randal E. Bryant
alerted me to the need for the precondition, INT_MIN <= x-y <= INT_MAX, and suggested the non-quick and
dirty version as a x. Both of these issues concern only the quick and dirty version. Nigel Horspoon observed on
July 6, 2005 that gcc produced the same code on a Pentium as the obvious solution because of how it evaluates (x <
y). On July 9, 2008 Vincent Lefvre pointed out the potential for overow exceptions with subtractions in r = y + ((x
- y) & -(x < y)), which was the previous version. Timothy B. Terriberry suggested using xor rather than add and
subract to avoid casting and the risk of overows on June 2, 2009.
https://graphics.stanford.edu/~seander/bithacks.html 4/30
10/13/2016 Bit Twiddling Hacks
f = (v & (v - 1)) == 0;
Sign extension is automatic for built-in types, such as chars and ints. But suppose you have a signed two's
complement number, x, that is stored using only b bits. Moreover, suppose you want to convert x to an int, which
has more than b bits. A simple copy will work if x is positive, but if negative, the sign must be extended. For
example, if we have only 4 bits to store a number, then -3 is represented as 1101 in binary. If we have 8 bits, then -3
is 11111101. The most-signicant bit of the 4-bit representation is replicated sinistrally to ll in the destination when
we convert to a representation with more bits; this is sign extending. In C, sign extension from a constant bit-width
is trivial, since bit elds may be specied in structs or unions. For example, to convert from 5 bits to an full integer:
int x; // convert this from using 5 bits to a full int
int r; // resulting sign extended number goes here
struct {signed int x:5;} s;
r = s.x = x;
The following is a C++ template function that uses the same language feature to convert from B bits in one
operation (though the compiler is generating more, of course).
template <typename T, unsigned B>
inline T signextend(const T x)
{
struct {T x:B;} s;
return s.x = x;
}
John Byrd caught a typo in the code (attributed to html formatting) on May 2, 2005. On March 4, 2006, Pat Wood
pointed out that the ANSI C standard requires that the biteld have the keyword "signed" to be signed; otherwise,
the sign is undened.
Sometimes we need to extend the sign of a number but we don't know a priori the number of bits, b, in which it is
represented. (Or we could be programming in a language like Java, which lacks bitelds.)
unsigned b; // number of bits representing the number in x
int x; // sign extend this b-bit number to r
int r; // resulting sign-extended number
int const m = 1U << (b - 1); // mask can be pre-computed if b is fixed
x = x & ((1U << b) - 1); // (Skip this if bits in x above position b are already zero.)
r = (x ^ m) - m;
The code above requires four operations, but when the bitwidth is a constant rather than variable, it requires only
two fast operations, assuming the upper bits are already zeroes.
A slightly faster but less portable method that doesn't depend on the bits in x above position b being zero is:
https://graphics.stanford.edu/~seander/bithacks.html 5/30
10/13/2016 Bit Twiddling Hacks
int const m = CHAR_BIT * sizeof(x) - b;
r = (x << m) >> m;
Sean A. Irvine suggested that I add sign extension methods to this page on June 13, 2004, and he provided m = (1
<< (b - 1)) - 1; r = -(x & ~m) | x;as a starting point from which I optimized to get m = 1U << (b - 1); r = -
(x & m) | x. But then on May 11, 2007, Shay Green suggested the version above, which requires one less operation
than mine. Vipin Sharma suggested I add a step to deal with situations where x had possible ones in bits other than
the b bits we wanted to sign-extend on Oct. 15, 2008. On December 31, 2009 Chris Pirazzi suggested I add the faster
version, which requires two operations for constant bit-widths and three for variable widths.
The following variation is not portable, but on architectures that employ an arithmetic right-shift, maintaining the
sign, it should be fast.
const int s = -b; // OR: sizeof(x) * CHAR_BIT - b;
r = (x << s) >> s;
Randal E. Bryant pointed out a bug on May 3, 2005 in an earlier version (that used multipliers[] for divisors[]),
where it failed on the case of x=1 and b=1.
w ^= (-f ^ w) & m;
https://graphics.stanford.edu/~seander/bithacks.html 6/30
10/13/2016 Bit Twiddling Hacks
On some architectures, the lack of branching can more than make up for what appears to be twice as many
operations. For instance, informal speed tests on an AMD Athlon XP 2100+ indicated it was 5-10% faster. An
Intel Core 2 Duo ran the superscalar version about 16% faster than the rst. Glenn Slayden informed me of the rst
expression on December 11, 2003. Marco Yu shared the superscalar version with me on April 3, 2007 and alerted
me to a typo 2 days later.
r = (v ^ -fNegate) + fNegate;
Avraham Plotnitzky suggested I add the rst version on June 2, 2009. Motivated to avoid the multiply, I came up
with the second version on June 8, 2009. Alfonso De Gregorio pointed out that some parens were missing on
November 26, 2009, and received a bug bounty.
This shaves one operation from the obvious way of combining two sets of bits according to a bit mask. If the mask is
a constant, then there may be no advantage.
for (c = 0; v; v >>= 1)
{
c += v & 1;
}
The naive approach requires one iteration per bit, until no more bits are set. So on a 32-bit word with only the high
set, it will go through 32 iterations.
// Option 1:
c = BitsSetTable256[v & 0xff] +
BitsSetTable256[(v >> 8) & 0xff] +
BitsSetTable256[(v >> 16) & 0xff] +
BitsSetTable256[v >> 24];
// Option 2:
unsigned char * p = (unsigned char *) &v;
c = BitsSetTable256[p[0]] +
BitsSetTable256[p[1]] +
BitsSetTable256[p[2]] +
BitsSetTable256[p[3]];
On July 14, 2009 Hallvard Furuseth suggested the macro compacted table.
Brian Kernighan's method goes through as many iterations as there are set bits. So if we have a 32-bit word with
only the high bit set, then it will only go once through the loop.
Published in 1988, the C Programming Language 2nd Ed. (by Brian W. Kernighan and Dennis M. Ritchie) mentions
this in exercise 2-9. On April 19, 2006 Don Knuth pointed out to me that this method "was rst published by Peter
Wegner in CACM 3 (1960), 322. (Also discovered independently by Derrick Lehmer and published in 1964 in a
book edited by Beckenbach.)"
Counting bits set in 14, 24, or 32-bit words using 64-bit instructions
unsigned int v; // count the number of bits set in v
unsigned int c; // c accumulates the total bits set in v
https://graphics.stanford.edu/~seander/bithacks.html 8/30
10/13/2016 Bit Twiddling Hacks
c += (((v & 0xfff000) >> 12) * 0x1001001001001ULL & 0x84210842108421ULL)
% 0x1f;
This method requires a 64-bit CPU with fast modulus division to be efcient. The rst option takes only 3
operations; the second option takes 10; and the third option takes 15.
Rich Schroeppel originally created a 9-bit version, similiar to option 1; see the Programming Hacks section of
Beeler, M., Gosper, R. W., and Schroeppel, R. HAKMEM. MIT AI Memo 239, Feb. 29, 1972. His method was the
inspiration for the variants above, devised by Sean Anderson. Randal E. Bryant offered a couple bug xes on May 3,
2005. Bruce Dawson tweaked what had been a 12-bit version and made it suitable for 14 bits using the same number
of operations on Feburary 1, 2007.
We can adjust the method for larger integer sizes by continuing with the patterns for the Binary Magic Numbers, B
and S. If there are k bits, then we need the arrays S and B to be ceil(lg(k)) elements long, and we must compute the
same number of expressions for c as S or B are long. For a 32-bit v, 16 operations are used.
The best method for counting bits in a 32-bit integer v is the following:
The best bit counting method takes only 12 operations, which is the same as the lookup-table method, but avoids the
memory and potential cache misses of a table. It is a hybrid between the purely parallel method above and the earlier
methods using multiplies (in the section on counting bits with 64-bit instructions), though it doesn't use 64-bit
instructions. The counts of bits set in the bytes is done in parallel, and the sum total of the bits set in the bytes is
computed by multiplying by 0x1010101 and shifting right 24 bits.
A generalization of the best bit counting method to integers of bit-widths upto 128 (parameterized by type T) is this:
v = v - ((v >> 1) & (T)~(T)0/3); // temp
v = (v & (T)~(T)0/15*3) + ((v >> 2) & (T)~(T)0/15*3); // temp
v = (v + (v >> 4)) & (T)~(T)0/255*15; // temp
c = (T)(v * ((T)~(T)0/255)) >> (sizeof(T) - 1) * CHAR_BIT; // count
https://graphics.stanford.edu/~seander/bithacks.html 9/30
10/13/2016 Bit Twiddling Hacks
See Ian Ashdown's nice newsgroup post for more information on counting the number of bits set (also known as
sideways addition). The best bit counting method was brought to my attention on October 5, 2005 by Andrew
Shapira; he found it in pages 187-188 of Software Optimization Guide for AMD Athlon 64 and Opteron
Processors. Charlie Gordon suggested a way to shave off one operation from the purely parallel version on
December 14, 2005, and Don Clugston trimmed three more from it on December 30, 2005. I made a typo with Don's
suggestion that Eric Cole spotted on January 8, 2006. Eric later suggested the arbitrary bit-width generalization to
the best method on November 17, 2006. On April 5, 2007, Al Williams observed that I had a line of dead code at the
top of the rst method.
Count bits set (rank) from the most-signicant bit upto a given position
The following nds the the rank of a bit, meaning it returns the sum of bits that are set to 1 from the most-signcant
bit downto the bit at the given position.
uint64_t v; // Compute the rank (bits set) in v from the MSB to pos.
unsigned int pos; // Bit position to count bits upto.
uint64_t r; // Resulting rank of bit at pos goes here.
Juha Jrvi sent this to me on November 21, 2009 as an inverse operation to the computing the bit position with the
given rank, which follows.
Select the bit position (from the most-signicant bit) with the given count (rank)
The following 64-bit code selects the position of the rth 1 bit when counting from the left. In other words if we start
at the most signicant bit and proceed to the right, counting the number of bits set to 1 until we reach the desired
rank, r, then the position where we stop is returned. If the rank requested exceeds the count of bits set, then 64 is
returned. The code may be modied for 32-bit or counting from the right.
uint64_t v; // Input value to find position with rank r.
unsigned int r; // Input: bit's desired rank [1-64].
unsigned int s; // Output: Resulting position of bit with rank r [1-64]
uint64_t a, b, c, d; // Intermediate temporaries for bit count.
unsigned int t; // Bit count temporary.
If branching is fast on your target CPU, consider uncommenting the if-statements and commenting the lines that
follow them.
while (v)
{
parity = !parity;
v = v & (v - 1);
}
The above code uses an approach like Brian Kernigan's bit counting, above. The time it takes is proportional to the
number of bits set.
// Variation:
unsigned char * p = (unsigned char *) &v;
parity = ParityTable256[p[0] ^ p[1] ^ p[2] ^ p[3]];
https://graphics.stanford.edu/~seander/bithacks.html 11/30
10/13/2016 Bit Twiddling Hacks
Randal E. Bryant encouraged the addition of the (admittedly) obvious last variation with variable p on May 3, 2005.
Bruce Rawles found a typo in an instance of the table variable's name on September 27, 2005, and he received a $10
bug bounty. On October 9, 2006, Fabrice Bellard suggested the 32-bit variations above, which require only one table
lookup; the previous version had four lookups (one per byte) and were slower. On July 14, 2009 Hallvard Furuseth
suggested the macro compacted table.
The method above takes around 4 operations, but only works on bytes.
The following method computes the parity of the 32-bit value in only 8 operations using a multiply.
unsigned int v; // 32-bit word
v ^= v >> 1;
v ^= v >> 2;
v = (v & 0x11111111U) * 0x11111111U;
return (v >> 28) & 1;
The method above takes around 9 operations, and works for 32-bit words. It may be optimized to work just on bytes
in 5 operations by removing the two lines immediately following "unsigned int v;". The method rst shifts and
XORs the eight nibbles of the 32-bit value together, leaving the result in the lowest nibble of v. Next, the binary
number 0110 1001 1001 0110 (0x6996 in hex) is shifted to the right by the value represented in the lowest nibble of
v. This number is like a miniature 16-bit parity-table indexed by the low four bits in v. The result has the parity of v
in bit 1, which is masked and returned.
Thanks to Mathew Hendry for pointing out the shift-lookup idea at the end on Dec. 15, 2002. That optimization
shaves two operations off using only shifting and XORing to nd the parity.
https://graphics.stanford.edu/~seander/bithacks.html 12/30
10/13/2016 Bit Twiddling Hacks
#define SWAP(a, b) ((&(a) == &(b)) || \
(((a) -= (b)), ((b) += (a)), ((a) = (b) - (a))))
This swaps the values of a and b without using a temporary variable. The initial check for a and b being the same
location in memory may be omitted when you know this can't happen. (The compiler may omit it anyway as an
optimization.) If you enable overows exceptions, then pass unsigned values so an exception isn't thrown. The XOR
method that follows may be slightly faster on some machines. Don't use this with oating-point numbers (unless you
operate on their raw integer representations).
Sanjeev Sivasankaran suggested I add this on June 12, 2007. Vincent Lefvre pointed out the potential for overow
exceptions on July 9, 2008
This is an old trick to exchange the values of the variables a and b without using extra space for a temporary
variable.
On January 20, 2005, Iain A. Fleming pointed out that the macro above doesn't work when you swap with the same
memory location, such as SWAP(a[i], a[j]) with i == j. So if that may occur, consider dening the macro as (((a) ==
(b)) || (((a) ^= (b)), ((b) ^= (a)), ((a) ^= (b)))). On July 14, 2009, Hallvard Furuseth suggested that on some machines,
(((a) ^ (b)) && ((b) ^= (a) ^= (b), (a) ^= (b))) might be faster, since the (a) ^ (b) expression is reused.
unsigned int x = ((b >> i) ^ (b >> j)) & ((1U << n) - 1); // XOR temporary
r = b ^ ((x << i) | (x << j));
As an example of swapping ranges of bits suppose we have have b = 00101111 (expressed in binary) and we want to
swap the n = 3 consecutive bits starting at i = 1 (the second bit from the right) with the 3 consecutive bits starting at j
= 5; the result would be r = 11100011 (binary).
This method of swapping is similar to the general purpose XOR swap trick, but intended for operating on individual
bits. The variable x stores the result of XORing the pairs of bit values we want to swap, and then the bits are set to
the result of themselves XORed with x. Of course, the result is undened if the sequences overlap.
On July 14, 2009 Hallvard Furuseth suggested that I change the 1 << n to 1U << n because the value was being
assigned to an unsigned and to avoid shifting into a sign bit.
https://graphics.stanford.edu/~seander/bithacks.html 13/30
10/13/2016 Bit Twiddling Hacks
}
r <<= s; // shift when v's highest bits are zero
On October 15, 2004, Michael Hoisie pointed out a bug in the original version. Randal E. Bryant suggested
removing an extra operation on May 3, 2005. Behdad Esfabod suggested a slight change that eliminated one
iteration of the loop on May 18, 2005. Then, on February 6, 2007, Liyong Zhou suggested a better version that loops
while v is not 0, so rather than iterating over all bits it stops early.
// Option 1:
c = (BitReverseTable256[v & 0xff] << 24) |
(BitReverseTable256[(v >> 8) & 0xff] << 16) |
(BitReverseTable256[(v >> 16) & 0xff] << 8) |
(BitReverseTable256[(v >> 24) & 0xff]);
// Option 2:
unsigned char * p = (unsigned char *) &v;
unsigned char * q = (unsigned char *) &c;
q[3] = BitReverseTable256[p[0]];
q[2] = BitReverseTable256[p[1]];
q[1] = BitReverseTable256[p[2]];
q[0] = BitReverseTable256[p[3]];
The rst method takes about 17 operations, and the second takes about 12, assuming your CPU can load and store
bytes easily.
On July 14, 2009 Hallvard Furuseth suggested the macro compacted table.
Reverse the bits in a byte with 3 operations (64-bit multiply and modulus division):
unsigned char b; // reverse this (8-bit) byte
The multiply operation creates ve separate copies of the 8-bit byte pattern to fan-out into a 64-bit value. The AND
operation selects the bits that are in the correct (reversed) positions, relative to each 10-bit groups of bits. The
multiply and the AND operations copy the bits from the original byte so they each appear in only one of the 10-bit
sets. The reversed positions of the bits from the original byte coincide with their relative positions within any 10-bit
set. The last step, which involves modulus division by 2^10 - 1, has the effect of merging together each set of 10 bits
(from positions 0-9, 10-19, 20-29, ...) in the 64-bit value. They do not overlap, so the addition steps underlying the
modulus division behave like or operations.
This method was attributed to Rich Schroeppel in the Programming Hacks section of Beeler, M., Gosper, R. W., and
Schroeppel, R. HAKMEM. MIT AI Memo 239, Feb. 29, 1972.
The following shows the ow of the bit values with the boolean variables a, b, c, d, e, f, g,and h, which
comprise an 8-bit byte. Notice how the rst multiply fans out the bit pattern to multiple copies, while the last
multiply combines them in the fth byte from the right.
abcd efgh (-> hgfe dcba)
* 1000 0000 0010 0000 0000 1000 0000 0010 (0x80200802)
-------------------------------------------------------------------------------------------------
0abc defg h00a bcde fgh0 0abc defg h00a bcde fgh0
& 0000 1000 1000 0100 0100 0010 0010 0001 0001 0000 (0x0884422110)
-------------------------------------------------------------------------------------------------
0000 d000 h000 0c00 0g00 00b0 00f0 000a 000e 0000
* 0000 0001 0000 0001 0000 0001 0000 0001 0000 0001 (0x0101010101)
-------------------------------------------------------------------------------------------------
0000 d000 h000 0c00 0g00 00b0 00f0 000a 000e 0000
0000 d000 h000 0c00 0g00 00b0 00f0 000a 000e 0000
0000 d000 h000 0c00 0g00 00b0 00f0 000a 000e 0000
0000 d000 h000 0c00 0g00 00b0 00f0 000a 000e 0000
0000 d000 h000 0c00 0g00 00b0 00f0 000a 000e 0000
-------------------------------------------------------------------------------------------------
0000 d000 h000 dc00 hg00 dcb0 hgf0 dcba hgfe dcba hgfe 0cba 0gfe 00ba 00fe 000a 000e 0000
>> 32
-------------------------------------------------------------------------------------------------
0000 d000 h000 dc00 hg00 dcb0 hgf0 dcba hgfe dcba
& 1111 1111
-------------------------------------------------------------------------------------------------
hgfe dcba
Note that the last two steps can be combined on some processors because the registers can be accessed as bytes; just
multiply so that a register stores the upper 32 bits of the result and the take the low byte. Thus, it may take only 6
operations.
Make sure you assign or cast the result to an unsigned char to remove garbage in the higher bits. Devised by Sean
Anderson, July 13, 2001. Typo spotted and correction supplied by Mike Keith, January 3, 2002.
The following variation is also O(lg(N)), however it requires more operations to reverse v. Its virtue is in taking less
slightly memory by computing the constants on the y.
unsigned int s = sizeof(v) * CHAR_BIT; // bit size; must be power of 2
unsigned int mask = ~0;
while ((s >>= 1) > 0)
{
https://graphics.stanford.edu/~seander/bithacks.html 15/30
10/13/2016 Bit Twiddling Hacks
mask ^= (mask << s);
v = ((v >> s) & mask) | ((v << s) & ~mask);
}
These methods above are best suited to situations where N is large. If you use the above with 64-bit ints (or larger),
then you need to add more lines (following the pattern); otherwise only the lower 32 bits will be reversed and the
result will be in the lower 32 bits.
See Dr. Dobb's Journal 1983, Edwin Freed's article on Binary Magic Numbers for more information. The second
variation was suggested by Ken Raeburn on September 13, 2005. Veldmeijer mentioned that the rst version could
do without ANDS in the last line on March 19, 2006.
Most programmers learn this trick early, but it was included for the sake of completeness.
for (m = n; n > d; n = m)
{
for (m = 0; n; n >>= s)
{
m += n & d;
}
}
// Now m is a value from 0 to d, but since with modulus division
// we want m to be 0 when it is d.
m = m == d ? 0 : m;
This method of modulus division by an integer that is one less than a power of 2 takes at most 5 + (4 + 5 * ceil(N /
s)) * ceil(lg(N / s)) operations, where N is the number of bits in the numerator. In other words, it takes at most O(N *
lg(N)) time.
Devised by Sean Anderson, August 15, 2001. Before Sean A. Irvine corrected me on June 17, 2004, I mistakenly
commented that we could alternatively assign m = ((m + 1) & d) - 1;at the end. Michael Miller spotted a typo
in the code April 25, 2005.
https://graphics.stanford.edu/~seander/bithacks.html 16/30
10/13/2016 Bit Twiddling Hacks
0xff000fff, 0xfc001fff, 0xf0003fff, 0xc0007fff,
0x0000ffff, 0x0001ffff, 0x0003ffff, 0x0007ffff,
0x000fffff, 0x001fffff, 0x003fffff, 0x007fffff,
0x00ffffff, 0x01ffffff, 0x03ffffff, 0x07ffffff,
0x0fffffff, 0x1fffffff, 0x3fffffff, 0x7fffffff
};
This method of nding modulus division by an integer that is one less than a power of 2 takes at most O(lg(N)) time,
where N is the number of bits in the numerator (32 bits, for the code above). The number of operations is at most 12
+ 9 * ceil(lg(N)). The tables may be removed if you know the denominator at compile time; just extract the few
relevent entries and unroll the loop. It may be easily extended to more bits.
It nds the result by summing the values in base (1 << s) in parallel. First every other base (1 << s) value is added to
the previous one. Imagine that the result is written on a piece of paper. Cut the paper in half, so that half the values
are on each cut piece. Align the values and sum them onto a new piece of paper. Repeat by cutting this paper in half
(which will be a quarter of the size of the previous one) and summing, until you cannot cut further. After performing
lg(N/s/2) cuts, we cut no more; just continue to add the values and put the result onto a new piece of paper as before,
while there are at least two s-bit values.
Devised by Sean Anderson, August 20, 2001. A typo was spotted by Randy E. Bryant on May 3, 2005 (after pasting
the code, I had later added "unsinged" to a variable declaration). As in the previous hack, I mistakenly commented
that we could alternatively assign m = ((m + 1) & d) - 1;at the end, and Don Knuth corrected me on April 19,
2006 and suggested m = m & -((signed)(m - d) >> s). On June 18, 2009 Sean Irvine proposed a change that
used ((n >> s) & M[s])instead of ((n & ~M[s]) >> s), which typically requires fewer operations because the
M[s] constant is already loaded.
Find the log base 2 of an integer with the MSB N set in O(N) operations (the obvious way)
unsigned int v; // 32-bit word to find the log base 2 of
unsigned int r = 0; // r will be lg(v)
The log base 2 of an integer is the same as the position of the highest bit set (or most signicant bit set, MSB). The
following log base 2 methods are faster than this one.
Find the integer log base 2 of an integer with an 64-bit IEEE oat
int v; // 32-bit integer to find the log base 2 of
int r; // result of log_2(v) goes here
union { unsigned int u[2]; double d; } t; // temp
t.u[__FLOAT_WORD_ORDER==LITTLE_ENDIAN] = 0x43300000;
t.u[__FLOAT_WORD_ORDER!=LITTLE_ENDIAN] = v;
t.d -= 4503599627370496.0;
r = (t.u[__FLOAT_WORD_ORDER==LITTLE_ENDIAN] >> 20) - 0x3FF;
The code above loads a 64-bit (IEEE-754 oating-point) double with a 32-bit integer (with no paddding bits) by
storing the integer in the mantissa while the exponent is set to 252. From this newly minted double, 252 (expressed as
a double) is subtracted, which sets the resulting exponent to the log base 2 of the input value, v. All that is left is
shifting the exponent bits into position (20 bits right) and subtracting the bias, 0x3FF (which is 1023 decimal). This
technique only takes 5 operations, but many CPUs are slow at manipulating doubles, and the endianess of the
architecture must be accommodated.
Eric Cole sent me this on January 15, 2006. Evan Felix pointed out a typo on April 4, 2006. Vincent Lefvre told me
on July 9, 2008 to change the endian check to use the oat's endian, which could differ from the integer's endian.
https://graphics.stanford.edu/~seander/bithacks.html 18/30
10/13/2016 Bit Twiddling Hacks
The lookup table method takes only about 7 operations to nd the log of a 32-bit value. If extended for 64-bit
quantities, it would take roughly 9 operations. Another operation can be trimmed off by using four tables, with the
possible additions incorporated into each. Using int table elements may be faster, depending on your architecture.
The code above is tuned to uniformly distributed output values. If your inputs are evenly distributed across all 32-bit
values, then consider using the following:
if (tt = v >> 24)
{
r = 24 + LogTable256[tt];
}
else if (tt = v >> 16)
{
r = 16 + LogTable256[tt];
}
else if (tt = v >> 8)
{
r = 8 + LogTable256[tt];
}
else
{
r = LogTable256[v];
}
Behdad Esfahbod and I shaved off a fraction of an operation (on average) on May 18, 2005. Yet another fraction of
an operation was removed on November 14, 2006 by Emanuel Hoogeveen. The variation that is tuned to evenly
distributed input values was suggested by David A. Buttereld on September 19, 2008. Venkat Reddy told me on
January 5, 2009 that log(0) should return -1 to indicate an error, so I changed the rst entry in the table to that.
https://graphics.stanford.edu/~seander/bithacks.html 19/30
10/13/2016 Bit Twiddling Hacks
unsigned int v; // 32-bit value to find the log2 of
const unsigned int b[] = {0x2, 0xC, 0xF0, 0xFF00, 0xFFFF0000};
const unsigned int S[] = {1, 2, 4, 8, 16};
int i;
Of course, to extend the code to nd the log of a 33- to 64-bit number, we would append another element,
0xFFFFFFFF00000000, to b, append 32 to S, and loop from 5 to 0. This method is much slower than the earlier
table-lookup version, but if you don't want big table or your architecture is slow to access memory, it's a good
choice. The second variation involves slightly more operations, but it may be faster on machines with high branch
costs (e.g. PowerPC).
The second version was sent to me by Eric Cole on January 7, 2006. Andrew Shapira subsequently trimmed a few
operations off of it and sent me his variation (above) on Sept. 1, 2007. The third variation was suggested to me by
John Owens on April 24, 2002; it's faster, but it is only suitable when the input is known to be a power of 2. On May
25, 2003, Ken Raeburn suggested improving the general case by using smaller numbers for b[], which load faster on
some architectures (for instance if the word size is 16 bits, then only one load instruction may be needed). These
values work for the general version, but not for the special-case version below it, where v is a power of 2; Glenn
Slayden brought this oversight to my attention on December 12, 2003.
Find the log base 2 of an N-bit integer in O(lg(N)) operations with multiply and lookup
uint32_t v; // find the log base 2 of 32-bit v
int r; // result goes here
https://graphics.stanford.edu/~seander/bithacks.html 20/30
10/13/2016 Bit Twiddling Hacks
8, 12, 20, 28, 15, 17, 24, 7, 19, 27, 23, 6, 26, 5, 4, 31
};
The code above computes the log base 2 of a 32-bit integer with a small table lookup and multiply. It requires only
13 operations, compared to (up to) 20 for the previous method. The purely table-based method requires the fewest
operations, but this offers a reasonable compromise between table size and speed.
If you know that v is a power of 2, then you only need the following:
Eric Cole devised this January 8, 2006 after reading about the entry below to round up to a power of 2 and the
method below for computing the number of trailing bits with a multiply and lookup using a DeBruijn sequence. On
December 10, 2009, Mark Dickinson shaved off a couple operations by requiring v be rounded up to one less than
the next power of 2 rather than the power of 2.
The integer log base 10 is computed by rst using one of the techniques above for nding the log base 2. By the
relationship log10(v) = log2(v) / log2(10), we need to multiply it by 1/log2(10), which is approximately 1233/4096,
or 1233 followed by a right shift of 12. Adding one is needed because the IntegerLogBase2 rounds down. Finally,
since the value t is only an approximation that may be off by one, the exact value is found by subtracting the result
of v < PowersOf10[t].
This method takes 6 more operations than IntegerLogBase2. It may be sped up (on machines with fast memory
access) by modifying the log base 2 table-lookup method above so that the entries hold what is computed for t (that
is, pre-add, -mulitply, and -shift). Doing so would require a total of only 9 operations to nd the log base 10,
assuming 4 tables were used (one for each byte of v).
This method works well when the input is uniformly distributed over 32-bit values because 76% of the inputs are
caught by the rst compare, 21% are caught by the second compare, 2% are caught by the third, and so on (chopping
the remaining down by 90% with each comparision). As a result, less than 2.6 operations are needed on average.
On April 18, 2007, Emanuel Hoogeveen suggested a variation on this where the conditions used divisions, which
were not as fast as simple comparisons.
c = *(const int *) &v; // OR, for portability: memcpy(&c, &v, sizeof c);
c = (c >> 23) - 127;
The above is fast, but IEEE 754-compliant architectures utilize subnormal (also called denormal) oating point
numbers. These have the exponent bits set to zero (signifying pow(2,-127)), and the mantissa is not normalized, so it
contains leading zeros and thus the log2 must be computed from the mantissa. To accomodate for subnormal
numbers, use the following:
const float v; // find int(log2(v)), where v > 0.0 && finite(v)
int c; // 32-bit int c gets the result;
int x = *(const int *) &v; // OR, for portability: memcpy(&x, &v, sizeof x);
c = x >> 23;
if (c)
{
c -= 127;
}
else
{ // subnormal, so recompute using mantissa: c = intlog2(x) - 149;
register unsigned int t; // temporary
// Note that LogTable256 was defined earlier
if (t = x >> 16)
{
c = LogTable256[t] - 133;
}
else
{
c = (t = x >> 8) ? LogTable256[t] - 141 : LogTable256[x] - 149;
}
}
On June 20, 2004, Sean A. Irvine suggested that I include code to handle subnormal numbers. On June 11, 2005,
Falk Hffner pointed out that ISO C99 6.5/7 specied undened behavior for the common type punning idiom *(int
*)&, though it has worked on 99.9% of C compilers. He proposed using memcpy for maximum portability or a
union with a oat and an int for better code generation than memcpy on some compilers.
Find integer log base 2 of the pow(2, r)-root of a 32-bit IEEE oat (for unsigned integer r)
const int r;
const float v; // find int(log2(pow((double) v, 1. / pow(2, r)))),
// where isnormal(v) and v > 0
int c; // 32-bit int c gets the result;
https://graphics.stanford.edu/~seander/bithacks.html 22/30
10/13/2016 Bit Twiddling Hacks
c = *(const int *) &v; // OR, for portability: memcpy(&c, &v, sizeof c);
c = ((((c - 0x3f800000) >> r) + 0x3f800000) >> 23) - 127;
So, if r is 0, for example, we have c = int(log2((double) v)). If r is 1, then we have c = int(log2(sqrt((double) v))). If r
is 2, then we have c = int(log2(pow((double) v, 1./4))).
On June 11, 2005, Falk Hffner pointed out that ISO C99 6.5/7 left the type punning idiom *(int *)& undened, and
he suggested using memcpy.
The average number of trailing zero bits in a (uniformly distributed) random binary number is one, so this O(trailing
zeros) solution isn't that bad compared to the faster methods below.
Jim Cole suggested I add a linear-time method for counting the trailing zeros on August 15, 2007. On October 22,
2007, Jason Cunningham pointed out that I had neglected to paste the unsigned modier for v.
Here, we are basically doing the same operations as nding the log base 2 in parallel, but we rst isolate the lowest 1
bit, and then proceed with c starting at the maximum and decreasing. The number of operations is at most 3 * lg(N)
+ 4, roughly, for N bit words.
Bill Burdick suggested an optimization, reducing the time from 4 * lg(N) on February 4, 2011.
Count the consecutive zero bits (trailing) on the right by binary search
unsigned int v; // 32-bit word input to count zero bits on right
unsigned int c; // c will be the number of zero bits on the right,
// so if v is 1101000 (base 2), then c will be 3
// NOTE: if 0 == v, then c = 31.
if (v & 0x1)
https://graphics.stanford.edu/~seander/bithacks.html 23/30
10/13/2016 Bit Twiddling Hacks
{
// special case for odd v (assumed to happen half of the time)
c = 0;
}
else
{
c = 1;
if ((v & 0xffff) == 0)
{
v >>= 16;
c += 16;
}
if ((v & 0xff) == 0)
{
v >>= 8;
c += 8;
}
if ((v & 0xf) == 0)
{
v >>= 4;
c += 4;
}
if ((v & 0x3) == 0)
{
v >>= 2;
c += 2;
}
c -= v & 0x1;
}
The code above is similar to the previous method, but it computes the number of trailing zeros by accumulating c in
a manner akin to binary search. In the rst step, it checks if the bottom 16 bits of v are zeros, and if so, shifts v right
16 bits and adds 16 to c, which reduces the number of bits in v to consider by half. Each of the subsequent
conditional steps likewise halves the number of bits until there is only 1. This method is faster than the last one (by
about 33%) because the bodies of the if statements are executed less often.
Matt Whitlock suggested this on January 25, 2006. Andrew Shapira shaved a couple operations off on Sept. 5, 2007
(by setting c=1 and unconditionally subtracting at the end).
Count the consecutive zero bits (trailing) on the right by casting to a oat
unsigned int v; // find the number of trailing zeros in v
int r; // the result goes here
float f = (float)(v & -v); // cast the least significant bit in v to a float
r = (*(uint32_t *)&f >> 23) - 0x7f;
Although this only takes about 6 operations, the time to convert an integer to a oat can be high on some machines.
The exponent of the 32-bit IEEE oating point representation is shifted down, and the bias is subtracted to give the
position of the least signicant 1 bit set in v. If v is zero, then the result is -127.
Count the consecutive zero bits (trailing) on the right with modulus division and lookup
unsigned int v; // find the number of trailing zeros in v
int r; // put the result in r
static const int Mod37BitPosition[] = // map a bit value mod 37 to its position
{
32, 0, 1, 26, 2, 23, 27, 0, 3, 16, 24, 30, 28, 11, 0, 13, 4,
7, 17, 0, 25, 22, 31, 15, 29, 10, 12, 6, 0, 21, 14, 9, 5,
20, 8, 19, 18
};
r = Mod37BitPosition[(-v & v) % 37];
https://graphics.stanford.edu/~seander/bithacks.html 24/30
10/13/2016 Bit Twiddling Hacks
The code above nds the number of zeros that are trailing on the right, so binary 0100 would produce 2. It makes
use of the fact that the rst 32 bit position values are relatively prime with 37, so performing a modulus division
with 37 gives a unique number from 0 to 36 for each. These numbers may then be mapped to the number of zeros
using a small lookup table. It uses only 4 operations, however indexing into a table and performing modulus division
may make it unsuitable for some situations. I came up with this independently and then searched for a subsequence
of the table values, and found it was invented earlier by Reiser, according to Hacker's Delight.
Count the consecutive zero bits (trailing) on the right with multiply and lookup
unsigned int v; // find the number of trailing zeros in 32-bit v
int r; // result goes here
static const int MultiplyDeBruijnBitPosition[32] =
{
0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
};
r = MultiplyDeBruijnBitPosition[((uint32_t)((v & -v) * 0x077CB531U)) >> 27];
Converting bit vectors to indices of set bits is an example use for this. It requires one more operation than the earlier
one involving modulus division, but the multiply may be faster. The expression (v & -v) extracts the least signicant
1 bit from v. The constant 0x077CB531UL is a de Bruijn sequence, which produces a unique pattern of bits into the
high 5 bits for each possible bit position that it is multiplied against. When there are no bits set, it returns 0. More
information can be found by reading the paper Using de Bruijn Sequences to Index 1 in a Computer Word by
Charles E. Leiserson, Harald Prokof, and Keith H. Randall.
On October 8, 2005 Andrew Shapira suggested I add this. Dustin Spicuzza asked me on April 14, 2009 to cast the
result of the multiply to a 32-bit type so it would work when compiled with 64-bit ints.
if (v > 1)
{
float f = (float)v;
unsigned int const t = 1U << ((*(unsigned int *)&f >> 23) - 0x7f);
r = t << (t < v);
}
else
{
r = 1;
}
The code above uses 8 operations, but works on all v <= (1<<31).
Although the quick and dirty version only uses around 6 operations, it is roughly three times slower than the
technique below (which involves 12 operations) when benchmarked on an Athlon XP 2100+ CPU. Some CPUs
will fare better with it, though.
On September 27, 2005 Andi Smithers suggested I include a technique for casting to oats to nd the lg of a number
for rounding up to a power of 2. Similar to the quick and dirty version here, his version worked with values less than
(1<<25), due to mantissa rounding, but it used one more operation.
https://graphics.stanford.edu/~seander/bithacks.html 25/30
10/13/2016 Bit Twiddling Hacks
v--;
v |= v >> 1;
v |= v >> 2;
v |= v >> 4;
v |= v >> 8;
v |= v >> 16;
v++;
In 12 operations, this code computes the next highest power of 2 for a 32-bit integer. The result may be expressed by
the formula 1U << (lg(v - 1) + 1). Note that in the edge case where v is 0, it returns 0, which isn't a power of 2; you
might append the expression v += (v == 0) to remedy this if it matters. It would be faster by 2 operations to use the
formula and the log base 2 method that uses a lookup table, but in some situations, lookup tables are not suitable, so
the above code may be best. (On a Athlon XP 2100+ I've found the above shift-left and then OR code is as fast as
using a single BSR assembly language instruction, which scans in reverse to nd the highest set bit.) It works by
copying the highest set bit to all of the lower bits, and then adding one, which results in carries that set all of the
lower bits to 0 and one bit beyond the highest set bit to 1. If the original number was a power of 2, then the
decrement will reduce it to one less, so that we round up to the same original value.
You might alternatively compute the next higher power of 2 in only 8 or 9 operations using a lookup table for
oor(lg(v)) and then evaluating 1<<(1+oor(lg(v))); Atul Divekar suggested I mention this on September 5, 2010.
Devised by Sean Anderson, Sepember 14, 2001. Pete Hart pointed me to a couple newsgroup posts by him and
William Lewis in February of 1997, where they arrive at the same algorithm.
for (int i = 0; i < sizeof(x) * CHAR_BIT; i++) // unroll for more speed...
{
z |= (x & 1U << i) << i | (y & 1U << i) << (i + 1);
}
Interleaved bits (aka Morton numbers) are useful for linearizing 2D integer coordinates, so x and y are combined
into a single number that can be compared easily and has the property that a number is usually close to another if
their x and y values are close.
https://graphics.stanford.edu/~seander/bithacks.html 26/30
10/13/2016 Bit Twiddling Hacks
0x1100, 0x1101, 0x1104, 0x1105, 0x1110, 0x1111, 0x1114, 0x1115,
0x1140, 0x1141, 0x1144, 0x1145, 0x1150, 0x1151, 0x1154, 0x1155,
0x1400, 0x1401, 0x1404, 0x1405, 0x1410, 0x1411, 0x1414, 0x1415,
0x1440, 0x1441, 0x1444, 0x1445, 0x1450, 0x1451, 0x1454, 0x1455,
0x1500, 0x1501, 0x1504, 0x1505, 0x1510, 0x1511, 0x1514, 0x1515,
0x1540, 0x1541, 0x1544, 0x1545, 0x1550, 0x1551, 0x1554, 0x1555,
0x4000, 0x4001, 0x4004, 0x4005, 0x4010, 0x4011, 0x4014, 0x4015,
0x4040, 0x4041, 0x4044, 0x4045, 0x4050, 0x4051, 0x4054, 0x4055,
0x4100, 0x4101, 0x4104, 0x4105, 0x4110, 0x4111, 0x4114, 0x4115,
0x4140, 0x4141, 0x4144, 0x4145, 0x4150, 0x4151, 0x4154, 0x4155,
0x4400, 0x4401, 0x4404, 0x4405, 0x4410, 0x4411, 0x4414, 0x4415,
0x4440, 0x4441, 0x4444, 0x4445, 0x4450, 0x4451, 0x4454, 0x4455,
0x4500, 0x4501, 0x4504, 0x4505, 0x4510, 0x4511, 0x4514, 0x4515,
0x4540, 0x4541, 0x4544, 0x4545, 0x4550, 0x4551, 0x4554, 0x4555,
0x5000, 0x5001, 0x5004, 0x5005, 0x5010, 0x5011, 0x5014, 0x5015,
0x5040, 0x5041, 0x5044, 0x5045, 0x5050, 0x5051, 0x5054, 0x5055,
0x5100, 0x5101, 0x5104, 0x5105, 0x5110, 0x5111, 0x5114, 0x5115,
0x5140, 0x5141, 0x5144, 0x5145, 0x5150, 0x5151, 0x5154, 0x5155,
0x5400, 0x5401, 0x5404, 0x5405, 0x5410, 0x5411, 0x5414, 0x5415,
0x5440, 0x5441, 0x5444, 0x5445, 0x5450, 0x5451, 0x5454, 0x5455,
0x5500, 0x5501, 0x5504, 0x5505, 0x5510, 0x5511, 0x5514, 0x5515,
0x5540, 0x5541, 0x5544, 0x5545, 0x5550, 0x5551, 0x5554, 0x5555
};
For more speed, use an additional table with values that are MortonTable256 pre-shifted one bit to the left. This
second table could then be used for the y lookups, thus reducing the operations by two, but almost doubling the
memory required. Extending this same idea, four tables could be used, with two of them pre-shifted by 16 to the left
of the previous two, so that we would only need 11 operations total.
Holger Bettag was inspired to suggest this technique on October 10, 2004 after reading the multiply-based bit
reversals here.
https://graphics.stanford.edu/~seander/bithacks.html 27/30
10/13/2016 Bit Twiddling Hacks
unsigned int x; // Interleave lower 16 bits of x and y, so the bits of x
unsigned int y; // are in the even positions and bits from y in the odd;
unsigned int z; // z gets the resulting 32-bit Morton Number.
// x and y must initially be less than 65536.
z = x | (y << 1);
The code above may be useful when doing a fast string copy in which a word is copied at a time; it uses 5
operations. On the other hand, testing for a null byte in the obvious ways (which follow) have at least 7 operations
(when counted in the most sparing way), and at most 12.
// More operations:
bool hasNoZeroByte = ((v & 0xff) && (v & 0xff00) && (v & 0xff0000) && (v & 0xff000000))
// OR:
unsigned char * p = (unsigned char *) &v;
bool hasNoZeroByte = *p && *(p + 1) && *(p + 2) && *(p + 3);
The code at the beginning of this section (labeled "Fewer operations") works by rst zeroing the high bits of the 4
bytes in the word. Subsequently, it adds a number that will result in an overow to the high bit of a byte if any of the
low bits were initialy set. Next the high bits of the original word are ORed with these values; thus, the high bit of a
byte is set iff any bit in the byte was set. Finally, we determine if any of these high bits are zero by ORing with ones
everywhere except the high bits and inverting the result. Extending to 64 bits is trivial; simply increase the constants
to be 0x7F7F7F7F7F7F7F7F.
For an additional improvement, a fast pretest that requires only 4 operations may be performed to determine if the
word may have a zero byte. The test also returns true if the high byte is 0x80, so there are occasional false positives,
but the slower and more reliable version above may then be used on candidates for an overall increase in speed with
correct output.
There is yet a faster method use hasless(v, 1), which is dened below; it works in 4 operations and requires no
subsquent verication. It simplies to
The subexpression (v - 0x01010101UL), evaluates to a high bit set in any byte whenever the corresponding byte in v
is zero or greater than 0x80. The sub-expression ~v & 0x80808080UL evaluates to high bits set in bytes where the
byte of v doesn't have its high bit set (so the byte was less than 0x80). Finally, by ANDing these two sub-expressions
the result is the high bits set where the bytes in v were zero, since the high bits set due to a value greater than 0x80
in the rst sub-expression are masked off by the second.
https://graphics.stanford.edu/~seander/bithacks.html 28/30
10/13/2016 Bit Twiddling Hacks
Paul Messmer suggested the fast pretest improvement on October 2, 2004. Juha Jrvi later suggested hasless(v,
1)on April 6, 2005, which he found on Paul Hsieh's Assembly Lab; previously it was written in a newsgroup post
on April 27, 1987 by Alan Mycroft.
Stephen M Bennet suggested this on December 13, 2009 after reading the entry for haszero.
Test if a word x contains an unsigned byte with value < n. Specically for n=1, it can be used to nd a 0-byte by
examining one long at a time, or any byte by XORing x with a mask rst. Uses 4 arithmetic/logical operations when
n is constant.
To count the number of bytes in x that are less than n in 7 operations, use
#define countless(x,n) \
(((~0UL/255*(127+(n))-((x)&~0UL/255*127))&~(x)&~0UL/255*128)/128%255)
Juha Jrvi sent this clever technique to me on April 6, 2005. The countlessmacro was added by Sean Anderson on
April 10, 2005, inspired by Juha's countmore, below.
To count the number of bytes in x that are more than n in 6 operations, use:
#define countmore(x,n) \
(((((x)&~0UL/255*127)+~0UL/255*(127-(n))|(x))&~0UL/255*128)/128%255)
The macro hasmorewas suggested by Juha Jrvi on April 6, 2005, and he added countmoreon April 8, 2005.
When m<n, this technique tests if a word x contains an unsigned byte value, such that m < value < n. It uses 7
arithmetic/logical operations when n and m are constant.
https://graphics.stanford.edu/~seander/bithacks.html 29/30
10/13/2016 Bit Twiddling Hacks
Note: Bytes that equal n can be reported by likelyhasbetweenas false positives, so this should be checked by
character if a certain result is needed.
#define likelyhasbetween(x,m,n) \
((((x)-~0UL/255*(n))&~(x)&((x)&~0UL/255*127)+~0UL/255*(127-(m)))&~0UL/255*128)
This technique would be suitable for a fast pretest. A variation that takes one more operation (8 total for constant m
and n) but provides the exact answer is:
#define hasbetween(x,m,n) \
((~0UL/255*(127+(n))-((x)&~0UL/255*127)&~(x)&((x)&~0UL/255*127)+~0UL/255*(127-(m)))&~0UL/255*128)
To count the number of bytes in x that are between m and n (exclusive) in 10 operations, use:
#define countbetween(x,m,n) (hasbetween(x,m,n)/128%255)
Juha Jrvi suggested likelyhasbetweenon April 6, 2005. From there, Sean Anderson created hasbetweenand
countbetweenon April 10, 2005.
The __builtin_ctz(v) GNU C compiler intrinsic for x86 CPUs returns the number of trailing zeros. If you are using
Microsoft compilers for x86, the intrinsic is _BitScanForward. These both emit a bsf instruction, but equivalents
may be available for other architectures. If not, then consider using one of the methods for counting the consecutive
zero bits mentioned earlier.
Here is another version that tends to be slower because of its division operator, but it does not require counting the
trailing zeros.
Thanks to Dario Sneidermanis of Argentina, who provided this on November 28, 2009.
https://graphics.stanford.edu/~seander/bithacks.html 30/30