Re: Advocating Lua on an embedded systems fair

[Ralph Hempel <rhempel@...>]

John Hind wrote:
> Yes, a well designed and useful poster.
>
> One nit-pick. I would prefer to quote "reasonable practical minimum"
> requirements rather than the absolute minimum achievable in a pure
> benchmarking exercise. On this basis 100K of flash seems low, and in the
> embedded context it would be useful to talk about RAM also as these
> resources are often very tight on embedded chips.
>
> I would suggest that an important threshold has just recently been crossed
> enabling a single chip Lua implementation to be a practical possibility:
> 512K Flash, 64K RAM (both bytes) with a 32Bit processing core. So far I've
> only found one chip in this class, the Atmel AVR32, but other manufacturers
> such as Microchip and Texas will no doubt soon catch up. I'm pretty sure in
> my own mind that 512K is the practical minimum for a full Lua system with
> libraries and space for the application (though a pure runtime virtual
> machine might make do with half that). I'm less confident I understand the
> RAM requirements though - any comments anyone?

I have a LOT of experience getting Lua to run on an AT91SAM7S256
which is an ARM7TDMI core with 256K FLASH and 64K RAM.

Using gcc, the Lua core (base,string,table,debug) and a run time
library take about 100K of FLASH and there's 58 K of heap available
after all the IO buffers and RAM code is set up.

The biggest problem with small RAM is the fragmentation of the
heap, and that a LOT of RAM is used up for what are essentially
read-only tables that hold functions.

So I can say that Lua in the deeply embedded space is possibly, but
it's difficult to make it dead reliable in the face of memory
constraints...

Ralph