[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lua 5.3.0 (work1) now available
- From: Justin Cormack <justin@...>
- Date: Tue, 9 Jul 2013 21:53:21 +0100
On Tue, Jul 9, 2013 at 9:38 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
> On Jul 9, 2013, at 6:37 AM, Roberto Ierusalimschy <roberto@inf.puc-rio.br>
> wrote:
>
> Sure. The idea is that the default would be 64-64, but restricted systems
> probably will prefer 32-32. (Moreover, systems with no 64-bit integers
> at all can use either 32-32 or 32-64).
>
>
> Currently, the problem is even worse, as many people use Lua without
> floating-point numbers. Mostly, we just ignore those uses (it is not
> "official" Lua) and pretend the problem does not exist. We hope the
> 32-32 option will allow many programmers in embedded systems to have
> a non-standard but officialy supported version of Lua, with 32-bit
> integers for performance and floating-point numbers when necessary.
>
>
> Just so I understand, what was the rationale for choosing 64 over 32 as the
> integer size? I was a little surprised by that given that integers would
> seem most useful on more restricted platforms where 64-bit integer is still
> (moderately) expensive (and also even that many "64-bit" OSes are compiled
> with 32-bit integers, such as OS X).
All OSs even 32 bit ones now make you deal with 64 bit quantities,
such as filesizes, timestamps, packet counts, free space on disks and
so on, and often other 64 bit interfaces. Some of these are hard to
manage with only 56 bits, such as bitfields. You do not use them a lot
necessarily, but when you do they are pretty essential.
Justin