Yes this is a well known problem. There are easy ways to implement this function over the range 0..63 and over the range 1..64 (one way has been mentioned in the comments), but 0..64 is more difficult.
Of course you can just take either the "left shifting" or "right shifting" mask generation and then special-case the "missing" n
,
uint64_t bitmask (unsigned short n) {
if (n == 64) return -((uint64_t)1);
return (((uint64_t) 1) << n) - 1;
}
Or
uint64_t bitmask (unsigned short n) {
if (n == 0) return 0;
uint64_t full = ~(uint64_t)0;
return full >> (64 - n);
}
Either way tends to compile to a branch, though it technically doesn't have to.
You can do it without if
(not tested)
uint64_t bitmask (unsigned int n) {
uint64_t x = (n ^ 64) >> 6;
return (x << (n & 63)) - 1;
}
The idea here is that we're going to either shift 1 left by some amount the same as in your original code, or 0 in the case that n = 64
. Shifting 0 left by 0 is just going to be 0 again, subtracting 1 sets all 64 bits.
Alternatively if you're on a modern x64 platform and BZHI is available, a very fast (BZHI is fast on all CPUs that implement it) but limited-portability option is:
uint64_t bitmask (unsigned int n) {
return _bzhi_u64(~(uint64_t)0, n);
}
This is even well-defined for n > 64
, the actual count of 1's will be min(n & 0xFF, 64)
because BZHI saturates but it reads only the lowest byte of the index.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…