lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hash: SHA1

On 15/01/10 00:46, Doug Rogers wrote:
> Maybe I misunderstand you here. In all my bit-busting code, if the shift
> is greater than the word size, I return 0 for the result of the shift.
> It is as if the bits are simply shifted out of the register as in an LFSR.

Yes, this is what I'd expect too --- I've done lots of low-level stuff,
and can't think of any situation where I'd expect a shift of 33 to
actually shift 1. *Rotates*, sure, but not shifts.

In C, x >> y is *undefined* if y > bitsizeof(x). I consider this to be

> Many, many years ago I found to my surprise and consternation that x86
> shifting did nothing (or was undefined?) when the count is greater than
>  or equal to the operand size. I remember singlestepping a debugger,
> thinking the result was crazy. I opened the data book and was surprised
> (well, not all that surprised) to see that I was the crazy one! Since
> then I always check the size and make it behave as I describe above. I
> realize it causes a branch to appear in the pipeline, but I prefer that
> to the alternative, non-commutative masking of the shift.

Many years ago when I was at Tao we found an interesting bug in our
compiler on the Transputer --- the system would lock up. We traced this
down to a shift right by zero. Turns out the Transputer microcode
implements shifts like this:

int rshift(int value, int count)
  while (--count)
    value >>= 1;
  return value;

We calculated that the instruction would actually terminate, after
having expensively done nothing, after about two weeks.

- -- 
┌─── ───── ─────
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla -