Re: Reducing Lua memory footprint - need help

["Bogdan Marinescu" <bogdan.marinescu@...>]

> 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).
The price point might be acceptable if it saves you from adding other
chips to your board (which also translates in a simpler (and cheaper)
PCB). Thanks for the trivia point, I didn't know that. The fact is
that I'd take any chip with 1M Flash/512k RAM, SIP or no SIP :)

> 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.
It's hard to make a "Lua Stamp", but not impossible, I see more and
more very small boards that are true wonders in terms of processing
power, and they include off-chip memory (let's not forget, for
example, that SST sells combined Flash/PSRAM devices that are a true
PCB space saver, albeit quite costly). And it seems that if you want
to head towards medium complexity embedded devices, BGA is the only
option most of the times, and I don't know of any hobbist that was
able to make DIY prototypes with BGAs. I did some PCBs myself at home,
but I was never able to go beyond 0.5mm, which is true for most of my
hobbists friends. And of course, nobody can do more than a 2 layer PCB
at home, unless their home happens to be inside a PCB manufacturing
facility.

> 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.
You're right. Although an embedded developer might see Lua as a RAM
killer, it's nothing compared with other scripting languages. TinyPy
is an interesting effort, but it's doomed to failure because it uses
Python, which is a great language _for desktops_, but not nearly as
great when MCUs come into play. Lua is better than Python in every
possible way in this area.

> 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).
I went from a lot of Sinclair Basic through a bit of Amstrad CPC
Basic, and finally lots and lots of GWBASIC combined with some QBASIC,
which were the only things my XT without a harddrive could run. And I
don't regret it, I learnt lots of lots of things doing BASIC. I
believe that the way you think about programming is more important
than the language you use (although I admit that there's an intrinsic
connection between them) and that you can write really crappy programs
in every language out there :) For me BASIC was a phase of my
development as a programmer, and frankly I have no idea what would've
happened if I didn't have any exposure to BASIC at all.
As for the industry, let's not forget that some are still using 8051
chips today ... I rest my case. Old habbits die hard. Plus, remember,
"never change a system that works" :)

> There was a discussion about this a few years back, but no solutions
> were presented IIRC.
I just implemented one :) I implemented two new data types ("light
functions" and "read-only tables") and by using them I reduced the
initial memory consumption (when you start the interpreter) from 18k
to about 12k, which isn't mind blowing, but it's still better than
nothing. I think I can do even better, but first I have to run the Lua
5.1 test suite on my mods and see how well (or bad) it performs.

Best,
Bogdan