Re: [ANN] Lua 5.3.0 (work1) now available

[Todd Coram <todd@...>]

On Tue, Jul 9, 2013, at 04:53 PM, Justin Cormack wrote:
> On Tue, Jul 9, 2013 at 9:38 PM, Tim Hill <drtimhill@gmail.com> wrote:
> > [snip]
> > 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
> 
A good point.

I work with (mostly embedded) 32-bit platforms and would heartily
welcome 64 bit ints as norm. I expect some performance (and size)
penalty from just using Lua (instead of C).  Forward looking design
favors 64 bits.  Currently, (default floating point) Lua on hardware
without FPUs are taking a performance (and size) hit. Going 64 bits
shouldn't cause any additional performance/size woes.

/todd