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

[Roberto Ierusalimschy <roberto@...>]

> 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.

There seems to be three somewhat independent issues:

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.

For point 2, we will try to accept any integer number modulo the
appropriate range.

For point 3, we are still unconvinced about signed results. The main
argument seems to be that the library is portable, but we are talking
here not about portability among different platforms, but about
portability between Lua with double numbers versus Lua with integer
numbers. There are already lots of incompatibilities between both
versions. Morever, programs that follow very simple rules remain
compatible. We still think that agreement with hexadecimal constants
(which are unsigned in vanilla Lua) is an important feature.

-- Roberto