lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Fri, Nov 5, 2010 at 12:19 PM, Michael Newberry <mnewberry@mirametrics.com> wrote:
>
>
> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On Behalf Of Thomas Harning Jr.
> Sent: Friday, November 05, 2010 9:07 AM
> To: Lua mailing list
> Subject: Re: [ANN] Lua 5.2.0 (work5) now available
>
> On Sat, Oct 30, 2010 at 9:58 PM, Michael Newberry
> <mnewberry@mirametrics.com> wrote:
> > Is a 64-bit version coming?
> >
> [...]
>
> > We don't use
> > 64-bit integers exposed to Lua... Anything requiring large
> > numbers/data-sizes have been abstracted away.
>
>        Well, that's the rub, isn’t it? I'm talking about a 64-bit Lua core that is 64-bit clean and supports 64-bit integers and table sizes.

Isn't your huge investment in Lua already working in 32-bit mode?

If you really want 64-bit integers, they can be added as you have the source, but what can't you do with 32-bit values that you need to do?

On a lighter point, did you see Knuth's comments about 64-bit pointers?:

A Flame About 64-bit Pointers
It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only waste half the memory, they effectively throw away half of the cache.
The gcc manpage advertises an option "-mlong32" that sounds like what I want. Namely, I think it would compile code for my x86-64 architecture, taking advantage of the extra registers etc., but it would also know that my program is going to live inside a 32-bit virtual address space.
Unfortunately, the -mlong32 option was introduced only for MIPS computers, years ago. Nobody has yet adopted such conventions for today's most popular architecture. Probably that happens because programs compiled with this convention will need to be loaded with a special version of libc.
Please, somebody, make that possible.

-joe