Re: bit.lshift and performance - luabitop v.s. lua-5.2.0-work4

[Miles Bader <miles@...>]

Roberto Ierusalimschy <roberto@inf.puc-rio.br> writes:
> 1 - shifts where the offset is not in [0,31]
> 2 - parameters outside the range of results
> 3 - signedness of results
>
> For point 1, we have no intention of changing our definition, which
> follows the definition that Knuth used in his Bitwise Tricks and
> Techniques.

... and for speed-critical applications, a user could probably avoid any
speed penalty for out-of-range shift-handling (branches etc), by using
something like:

  bit.lshift (NUM, bit.band (COUNT, 31))

[instead of plain "bit.lshift (NUM, COUNT)"]

... if he was sure that COUNT was never _actually_ out of range (or if
the "modulo" behavior actually made sense for his applications.

Presumably luajit could then recognize that no out-of-range testing was
necessary, and either toss out the "&" on architectures where the native
shift operators do it implicitly, or use an explicit "&" on
architectures where they don't (per Mike's description).

This has the advantage of being fast, but also being explicit, making
the code more readable for people that don't know all the subtleties of
the shift operators.

-Miles

-- 
Insurrection, n. An unsuccessful revolution.