Re: Extending Lua for multiple light userdata types

[Roberto Ierusalimschy <roberto@...>]

> > I have been playing a little with the idea of introducing an integer
> > type in Lua. I have intended to present some initial thoughts in the
> > workshop.
> 
> Doubles can represent integers in the range (-2^53, 2^53) exactly, so
> why a separate integer type? OK, I'm mainly programming for x86 but if
> speed was ever an issue it certainly no longer is with SSE/AVX
> available.  If the main benefit is 64-bit bit operations then why not
> a "bit set" type without the additional coercion rules?  Still, it
> does impact size, at least on 32-bit systems.

Speed is not an issue for "regular" systems, but it is always an
issue for embedded systems, which frequently compile Lua changing
double to long as its numerical type.

A "number" with 64 bits seem much more natural than an extra "bit set"
type, which would require a bunch of new functions to manipulate.

The impact on memory should be nil (except for the NaN trick, that Lua
5.1 never used anyway): doubles already use 64 bits. Anyway, the idea
is that it should be easy to compile Lua both with 32 and with 64-bit
integers, as well as with single or double floats.

One of the main reasons that Lua uses double is to support full
32 bits. With a natural 32-bit integer, you could compile Lua
with single floats and then really reduce memory usage.

But the introduction of integers also solve a big reverse
problem. Frequently, restricted systems compile Lua with longs as its
number type. And frequently, there is the problem of how to manipulate
floating point numbers on those systems.  Lua with 32-bit integers and
single floats would use much less memory, offering full 32 bits when
needed, the speed of integers for hardware without FP support, and
floating point number when necessary.

-- Roberto