CODEWITHSUNDEEP
luabytecode
user1697014
user1697014

Reputation:

Cross-architecture luac output

I'm working on a so-called cartridge, for the geo-location based WheriGo (http://wherigo.com) game. The architecture that is used for these cartridges is 32-bit and big endian. However, my luac will create chunks that are 64-bit and little endian.

While there is an online compilation service for WheriGo, I'd rather be able to produce the proper binary format for myself. Especially, because there are things I'd rather keep a bit obscured in a stripped chunk, loaded by loadstring(), rather than having the full debug information available.

So my question is this: How hard would it be to generate a lua tool chain, that generates byte code for a different architecture, than the one it is running under?

Upvotes: 9

Views: 949

Answers (2)

mirabilos
mirabilos

Reputation: 5327

You could always run a 32-bit big-endian machine as VM, e.g. Aurélien’s prebuilt images for Debian/mips (notes). It’ll be slow but work and can be automated easily. (Do a dist-upgrade to at least wheezy from squeeze, then get latest Lua.)

I've run VMs like that often enough… it's slow, but I think of it as batch processing: I start a job (apt or compile), then look at it occasionally (or: the next day) to see whether it finished. Most of the time, this works out pretty well; some things of course do not work right in emulation (e.g. due to emulator bugs or differences), but to get a big-endian 32-bit Lua, this might work).

Suggested reading: lua bytecode portability and middle-endian doubles on ARM (both on the lua mailing list) – since PocketPC machines are mostly ARM, you might run into that. Best to check the actual Wherigo cartridges to see what settings they use…

The gist of these postings is: endianness, sizeof(int), sizeof(size_t), sizeof(Instruction), sizeof(lua_Number), and type of lua_Number must be the same for the bytecode to be compatible across architectures (says Luiz Henrique de Figueiredo), and middle-endian floats (both single and double) do exist in the wild (steve donovan and Dimiter 'malkia' Stanev).

Do tell if you do it – I'm interested because I'm a geocacher myself (though need to figure out how to play cartridges, no player for my platforms).

Upvotes: 1

mksteve
mksteve

Reputation: 13073

If the floating point representation of both machines is compatible, then this should be just modifications to ldump.c and lundump.c

Care taken to ensure types E.g. long are same size. I have done this for integer lua on x86,x64

Upvotes: 1

Related Questions