Re: [ANN] Lua 5.2.0 (work1) now available
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: [ANN] Lua 5.2.0 (work1) now available
- From: Roberto Ierusalimschy <roberto@...>
- Date: 2010年1月15日 12:55:03 -0200
> Summary:
> - Inputs to bit operations need to be converted in a consistent and
> platform-independent way, respecting modular arithmetic requirements.
We would like to do that. But we do not know a reasonable way to do it
in ANSI C89.
> - Outputs of bit operations need to be signed.
We still dissagree. I cannot see how bit.not(0) could not be equal
to 0xffffffff. Output of bit operations should be equal to the
corresponding hexa constants. (The manual is incorrect: it should state
something along the previous line. If 0xffffffff is -1 in a specific
version of Lua, so should be bit.not(0).) In C, if you get the result of
a bit operation as a lua_Number and cast it to (unsigned int), you get
consistent results with different types of lua_Number.
> - Shift and rotate instructions need to be explicitly named.
We were already considering changing that. (But both directions will
treat a negative shift as "shift in the other direction".)
> - Shift counts should be masked by the bit width.
Not convinced (see below).
> - Arithmetic right shift is not optional.
Not sure.
> - Ignoring the naming conventions defined by the most popular
> existing libraries is unwise, because it forces all users to
> rewrite their code (FYI: BitOp inherited the names from lbitlib).
That was a confusion. We should use the same names.
When discussing language design, performance is always present. But
we do not think that, in a scripting language, such as Lua, we should
consider a change in an API just to avoid an extra conditional or a jump
misprediction. For LuaJIT, I am sure it will be able to eliminate
these extra tests in most cases.
-- Roberto