Re: Reducing Lua memory footprint - need help

["Tony Bauer" <luatony@...>]

On Tue, Oct 14, 2008 at 12:37 AM, Bogdan Marinescu
<bogdan.marinescu@gmail.com> wrote:
> Don't forget about this one:
>
> http://www.atmel.com/dyn/products/product_card.asp?part_id=3680
>
> 2M Flash/256k RAM of _internal_ memory. Excellent chip, but they were
> so absorbed to cram as much memory as possible inside it, that they
> completely forgot about the interfaces. It doesn't even have a SPI
> master on-board, not to mention fancy stuff like USB, Ethernet and
> others.
The FR40162S is also a little pricey ($23) and a BGA.  Trivia point:
both it and the STR9xx are SIPs (the flash memory is actually a
separate die).

>> If you can live without on-chip flash, the champion is the Renesas
>> SH726x MCU's with 1M SRAM.  Using off-chip memory really does increase
>> the complexity, and it's hard to match the bandwidth of on-chip
>> memory.
> And yet it seems to be the only realistic way (at the moment) to go
> with eLua and "serious applications", the exact ones that KHMan
> mentioned in an earlier reply. Lua likes RAM. Which is perfectly fine,
> of course, just not very fortunate for small embedded systems.
>
I've been involved with a custom AT91RM9200 board; it's definitely
hard to make a "Lua Stamp" with similar size and cost to a BASIC stamp
using off chip memory.  There are other issues; the AT9100 definitely
seems bus-limited (and the small cache doesn't help).  And most chips
over 200 MHz and everything over 208 pins is a BGA, which is much
harder to design and prototype.

Lua's RAM usage also seems to much less than any competitor with
similar capabilities (BASIC and FORTH don't count) - e.g. TinyPy may
only use 64K of code, but at least 400K of RAM.

> That's one way to put thing, I suppose :) Personally, I had a bit of
> fun with BASIC Stamps. They were neat, easy to use, and although quite
> limited in capabilities, I was always impressed with the things one
> could do with them. Its main achievemnt IMO is that it teaches people
> how to work with systems with very limited resources, which seems to
> become something of a lost art nowadays. And yes, I know that Dijkstra
> told to the world that it's practically impossible to teach good
> programming to someone with previous exposure to BASIC, but I don't
> agree with that. It's perfectly fine as long as your world is not
> limited to BASIC. Which is an universal truth, not specific to BASIC.
>

I've done TRS-80 BASIC, AppleSoft, GWBASIC and such and have no desire
to ever see them again.  Unfortunately, many industrial automation
vendors (such as Galil, Animatics, IMS/Schneider) have no clue how to
create a good programming language, and what I get to use is similar
to crappy BASICs - or worse (such as the MicroMo MVP).

> On-topic: I realised yesterday that even if I do implement my "read
> only tables", I'll still have another problem: the Lua functions. Or,
> to be more precise, the C functions one calls from Lua, which are
> still regular Lua closure types, thus are malloc-ed and take memory. I
> probably need to implement "lightweight functions", which are just
> like lightweight userdata, but they are pointers to C functions and
> are callable objects in Lua. I'll look more into this when I have more
> time.
>
> Best,
> Bogdan

There was a discussion about this a few years back, but no solutions
were presented IIRC.
Cheers,
Tony