Re: Cross Compiling Lua

[RLake@...]

At the risk of being obvious, it seems to me that Lua has a cross-platform
format: source code. The Lua parser is small and fast, and although I was
initially skeptical, I have to agree with Wim [private communication] that
zlib-compressed source is smaller than zlib-compressed vmcode (unless you
have lots and lots and lots of comments). So if you have an application
which, for example, exchanges Lua executables (possibly as data
descriptions) across a slow network, you are probably better off stripping
comments and compressing the source code; you could decompress and compile
at the receiving end, and cache the compiled version, possibly stripping
debugging information to save storage (see luac.c for how to do this; it is
one of the few things luac.c actually does, see below.)

I understand that it might be desirable for an embedded system on a
microcontroller with limited RAM to not include the parser and lexer; it
should be quite straightforward to create a Lua with the appropriate
characteristics, though ("#define int short" is a good start) and that
could be used as a cross-compiler (Disclaimer: I haven't actually tried
this, but I could be persuaded to.)

It seems unlikely that creating a platform-independent binary transfer
format would provide much in the way of benefits: the files would be even
larger than vm files; reading the file would be slower and possibly not
much faster than compiling;  there are bound to be odd problems with number
formats; and it would bulk up the Lua executable, which is contrary to the
point of having a small executable for embedded systems.

By the way, it is worth noting that luac does not actual contain a
compiler. It is a very light wrapper around the Lua core, which includes a
compiler; luac does practically nothing you could not do in a few lines
with the standard api. It is worth looking at luac.c as an example of how
to integrate Lua in an application.

Rici