[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.2.0 (work1) now available
- From: David Given <dg@...>
- Date: Fri, 15 Jan 2010 11:22:47 +0000
-----BEGIN PGP SIGNED MESSAGE-----
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)
value >>= 1;
We calculated that the instruction would actually terminate, after
having expensively done nothing, after about two weeks.
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----