lua-users home
lua-l archive

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


>What seems to be happening is that the 64-bit unsigned integers in the lua
>state (->GCthreshold and ->nblocks) are being corrupted, because as far as I
>can see the compilers are generating 32-bit arithmetic instructions for the
>garbage collection/ string table resizing routines.

I'm not sure where the problem lies or whether it's the compiler's fault, but
if something can be done in the source code to avoid this, we'd like to hear
about it.

We definitely want to see Lua running on the PS2 as smoothly as possible.
Lua on the PS2 has been mentioned before in this list. I think it ran ok.

>When we ran our game through the Performance Analyser, Lua showed up as the
>worst single culprit for performance, and a lot of that was due to double
>precision operations. Even after defining LUA_NUM_TYPE to be float instead
>of double, there are still many functions both in the API and internally
>which expect double precision arguments.

That's odd. There's no mention of double in the code. Perhaps you mean the
use of strtod in lua_str2number and sprintf in lua_number2str. These can be
redefined if necessary.

>Does anyone know what the
>implications of a global search and replace for float to double would be?

Like I said, there are no explict doubles. (What version of Lua are you using?)

>How many of the 64 bit values (long is 64 bit on a PlayStation2) used
>throughout the library are actually required to be 64-bit?

None. See lu_hash and lu_mem in llimits.h.
--lhf