Adding unsafeShiftL, unsafeShiftR to Data.Bits(Bits)

Johan Tibell has proposed that we add unsafeShiftL and unsafeShiftR methods to the Bits class, as per the patch here: http://hackage.haskell.org/trac/ghc/attachment/ticket/5414/0001-Add-unsafeSh... I've talked this through with Johan, and we came to the conclusion that while "unsafeShiftL" is a bit unsightly, this is the most workable solution. For example, optimising away the test in shiftL directly in the backend is not possible when compiling via LLVM, which only provides the unsafe operation as a primitive. Any objections before I push this in? Cheers, Simon

On Tue, Aug 16, 2011 at 4:06 PM, Simon Marlow
I've talked this through with Johan, and we came to the conclusion that while "unsafeShiftL" is a bit unsightly, this is the most workable solution. For example, optimising away the test in shiftL directly in the backend is not possible when compiling via LLVM, which only provides the unsafe operation as a primitive.
In fact it's not even possible on plain x86, as the CPU masks out the last 5 bits in the shift amount and only uses those when shifting (i.e. the shift amount is always mod 32). There's no way to optimize away the branch used in `shiftL` and the rest for shifts of unknown size. Johan

On 16 August 2011 15:39, Johan Tibell
the CPU masks out the last 5 bits in the shift amount and only uses those when shifting
As an aside, this may be how it's specified now in all modern x86(-64) CPUs, but it definitely wasn't true for all CPUs. Some older x86 CPUs actually would set the value to zero if the shift amount was greater than the word length. (I'm not sure which, but may have been different in early 386 CPUs and Athlon CPUs.) / Thomas

On Sun, Aug 21, 2011 at 19:42, Thomas Schilling
On 16 August 2011 15:39, Johan Tibell
wrote: the CPU masks out the last 5 bits in the shift amount and only uses those when shifting
As an aside, this may be how it's specified now in all modern x86(-64) CPUs, but it definitely wasn't true for all CPUs. Some older x86 CPUs actually would set the value to zero if the shift amount was greater than the word length. (I'm not sure which, but may have been different in early 386 CPUs and Athlon CPUs.)
FWIW I vaguely recall a bit of an outcry when this changed on Intel CPUs. It may have been around the 80486. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On August 22, 2011 01:57:32 Brandon Allbery wrote:
FWIW I vaguely recall a bit of an outcry when this changed on Intel CPUs. It may have been around the 80486.
I just checked my copy of the Intel486 Programmer's Reference Manual and s[h/a][l/r] -- no masking sh[l/r]d -- masking Cheers! -Tyson
participants (5)
-
Brandon Allbery
-
Johan Tibell
-
Simon Marlow
-
Thomas Schilling
-
Tyson Whitehead