lua-users home
lua-l archive

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


> > I think Lua has a union in llimits.h which has double in it. I think
> > it's supposed to be the size of an instruction. This only needs to
be 32
> > bit, not 64 so you can save memory. I think the running faster
reference
> > was wrt to removing all instances of double from Lua.
> 
> This union ensures that all memory allocated with lua_newuserdata
> satisfies all allignment restrictions (like the result of malloc),
> so that you can store any kind of data in that area. You can change
> that simply redefining LUSER_ALIGNMENT_T to a type with the maximum
> allignment you need in your application (e.g.,
-DLUSER_ALIGNMENT_T=int).

Bah humbug. You're ahead of me again. I should have checked the source.
I just recalled that I went in and changed this manually with a global
search and replaced for long, not what was there.

> > I think the only problem I have now is long, which is 64 bit on the
PS2.
> > There are only a few occurrences in the Lua code, but nevertheless
it
> > makes sense to remove them (for PS2). It would be nice if the longs
were
> > ints or user defined. If in Lua long is assumed to be the same size
as
> > int (i.e. the machines native word size) there seems little point in
> > using it at all.
> 
> Lua uses longs whenever it needs a type that is at least 32 bits or
> where an int may be too small (even a 32 bit int). For most uses we do
> define new types (e.g., Instruction, ls_nstr, lu_mem). In a few
places,
> where performance is not critical, we use long directly in the code to
> avoid the complexity of too many user-defined types.

A 32 bit int might be too small? I've removed all longs and nothing
seems to break? Would you only need >32 bit ints on a >32 bit platform?
What are the implications of moving all longs?

Nick