> 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. I'm still waiting for the JavaScript kickstarter chip to be delivered so time will tell how useful it is. JavaScript has the big advantage that being intrinsically event-driven it fits well with interrupt-driven microcontroller applications, but compared to Lua it is an ugly, bloated language, and Python is barely better without even the advantage of being event-driven. But I think it would be relatively easy to write an event/interrupt driven scheduler for Lua coroutines.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature