I believe a chip with 512k of RAM is good for a lot of real world eLua
applications. <Bogdan Marinescu>
Have you considered doing a Kickstarter like the Python and JavaScript
examples I referenced?
I don't think Lua is taking lot of RAM, all dynamic languages that I know
of need a lot of RAM (for good reasons) . <Bogdan Marinescu>
There is an idea that has been rattling about in my mind for a few years
now, but it may still be a little half-baked. This is that it should be
possible to allocate the bytecodes of functions/closures separately from any
required volatile storage (for example upvalues). The latter would be stored
in RAM, while the bytecodes would be stored as immutable strings (strings in
Lua already being byte-safe and immutable). Then all you'd need is the
ability to compile the memory allocation functions to allocate strings in
EPROM. Not only does this take the bytecodes (and the strings) out of the
RAM budget, but it also allows string fragment compression/deduplication to
be used on bytecode sequences as well. If source is recompiled and generates
the same bytecode sequence, the deduplication automatically eliminates it
using no more memory. On von Neumann architectures everything would be
allocated from RAM but still benefit from compression, while on
microcontrollers the memory allocation function could be replaced by one
with access to both EPROM and RAM. Garbage collection would also need to be
modified so strings/bytecodes (if allocated in non-volatile memory) are only
collected on demand.
