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

[Leo Razoumov <slonik.az@...>]

On 2010-10-13, Mike Pall <mikelu-1010@mike.de> wrote:
> [..snip..]
>  Lua 5.2 would break many of them. Even worse, users cannot load
>  Lua BitOp anymore, since the incompatible, internal Lua 5.2
>  library takes precedence!
>
>  There are many more incompatibilities, e.g. the signedness of the
>  results depends on the Lua number type. Passing inputs for bit
>  operations from C to Lua with lua_pushinteger won't work portably,
>  too. Code that happens to work on your desktop will break in
>  unpredictable ways on embedded platforms with Lua 5.2.
>
>  Also, it doesn't support modular arithmetic for bit operations,
>  which is a major use case in crypto stuff. E.g. the following
>  expression from MD5 relies on additions with wrapping semantics:
>
>   y = rol(bxor(c, bor(b, bnot(d))) + a + x, s) + b
>
>  That happens to work on x86 with Lua 5.2 by accident, but breaks
>  badly e.g. on ARM. In more complicated code you'll only notice
>  this when you hit just the right input operands. Good luck ...
>
>  The Lua 5.2 bit library is incompatible with Lua BitOp, it's
>  semantics are not well-defined and it's not cross-platform-safe.
>  It should really be renamed or dropped.
>
> [..snip..]
>
>  --Mike

I am doing lots of bit operations in communications theory simulations
(mostly in C/C++ by now) and would like to do it in Lua for fast
prototyping.

Mike's analysis and remarks raise quite important issues.

It would be great if somebody from the Lua core team would
specifically address them.

x86-32/x86-64/ARM compatibility is quite important in what I and my
colleagues are doing. It would be nice to come up with one design that
supports multiple architectures with minimal incompatibilities.

--Leo--