Re: Reducing Lua memory footprint - need help

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

> On the ARM side, the RAM situation is getting a little better.  The
> STR9xx series has 96K RAM (but some of it has to be used for Ethernet
> buffers). NXP also has some with 96K, plus new models coming (LPC29xx)
> with 120K (but 32K of that is instruction only), and the Atmel
> AT91SAM7X512 has 128K RAM.
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. Of course, there's no such thing as a "perfect chip". I'd sure
like to see a combination between this chip and Luminary'
LM3S8962/LM3S6965 Cortex-M3 chips, which probably have everything
you'd ever need in terms of peripherals (including Ethernet MAC _and_
PHY on chip), but it only has 256k Flash/64k RAM.

> 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.

> USB development sticks are a good way to experiment with MCU's; for
> example, the STR9 COM-Stick is about $65, has a STR9xx CPU, Ethernet,
> USB, and CAN transceiver -- and best of all, Bogdan has already ported
> eLua to the STR9 series.
...and using exactly the STR9-comStick as the platform :) Quite a
weird platform though.

> Question for Bogdan: do you test each version (386, LM3S, STR9,
> AT91SAM7, LPC2888) on a development board?  Even with inexpensive
> development kits, that can get expensive if you're paying for all
> those boards.
When I started eLua, I already had the AT91SAM7 board laying around
(given to me by someone else for a previous project), waiting to be
put to good use again. I got the LM3S and STR9 boards for free after
getting in contact with Luminary/ST and asking them if they're willing
to spare a board for my project. And I bought the LPC2888 for the
project myself, and it was damn expensive. And I don't even like it
that much. But at least I got eLua running on it.

> And, yes, I would like to see BASIC Stamps, and all similar crappy
> little languages (some of which I have to use at work, ugh!), die a
> well deserved death before they corrupt more programmers with bad
> programming practices.
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.

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