[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.2.0 (work1) now available
- From: Roberto Ierusalimschy <roberto@...>
- Date: Mon, 18 Jan 2010 12:33:24 -0200
> Roberto Ierusalimschy wrote:
> > > 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.
> You can deal with it the same way you deal with popen(): make it
> conditional, but enable it by default in this case (*).
> The bit library needs to be made conditional, anyway: it should be
> disabled for 32 bit floats, since the semantics just don't make
> any sense there (loss of precision).
> (*) Lua BitOp works on 16, 32 and 64 bit platforms with lua_Number
> types IEEE 754 double, int32_t or int64_t. I've not found a single
> OS/CPU/compiler combination that doesn't like it.
I am not worried about different number types or specific platforms.
Our "contract" is with doubles and ANSI. Although Lua provides some
optimizations for some arquitechtures, it always provides a fallback
case that should work with any ANSI compiler.
The bit library should not be conditional for this contract. So we need
an ANSI way to do that input.
> [About the FP representation example: I've picked apart FP numbers
> with bit operations in the past. But 1) it uses a biased exponent
> and not a signed one and 2) there is no need for a bidirectional
> shift. This use case rather asks for a masked shift count!]
We all did it. The biased exponent becomes a signed one as soon
as you subtract the bias. Except for the special cases (NaN, inf,
denormalized), the conversion is trivial with bidirectional shift
*and* shifting out all bits if exponent is too large/too small.
> > > - Shift counts should be masked by the bit width.
> > Not convinced (see below).
> You do not present any related arguments below.
It is the one about performance.
> I repeat my arguments for masking the shift counts:
> - It enforces defined behavior.
Shifting out also enforces defined behavior.
> - It's based on actual needs of users.
> - It simplifies a majority of actual use cases.
I still did not see the evidence.
> - It works consistently for *all* shift or rotate instructions.
The same for shifting out. (rotate also does specify that it masks the
count: it just happens that rotate(x, 33) == rotate(x, 1).)
> - It's consistent with the input conversions for other bit op
> arguments that respect the requirements of modular arithmetics.
> > 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.
> This makes it sound as though a "scripting language" is some
> inferior creature that doesn't deserve as much attention to its
Maybe my English is not that clear, but I cannot see how what I said
could sound like "a 'scripting language' is some inferior creature that
doesn't deserve as much attention to its design."
> And Lua is rarely used in the way that Perl or Bash is, so
> the name is undeserved as well.
Lua *is* a scripting language.
> If we use the "it's a scripting language, it can be slow" excuse
> too often, we end up with Python. If we use the "it's a scripting
> language, API design doesn't matter" excuse, we end up with PHP.
> I sincerely hope I'll never see that day.
Again you are changing my words. This makes a discussion with you too
strenuous, which is sad. I did not say that "it can be slow". What
I said is that Lua has a different time scale than C: One extra "if"
in a library function should not be considered a relevant cost if it
improves the API. And where on hell did I say that "API design doesn't
matter"?? I said (or tried to sell, again maybe my English is too poor)
exactly the opposite.