Re: Reducing Lua memory footprint - need help

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

> Would that be something in range of AVR32 or PIC32? They look mighty interesting for projects needing less than an ARM, but I've always wondered if a garbage-collecting runtime is suitable for such MCUs... Some of those USB/Ethernet-integrated versions are so attractive if we can Lua-script, but those lower-end ones like PIC18 would probably need some kind of fixed allocation scheme.

Yes, AVR32/PIC32 are very likely targets. And
<shameless_self_promotion> the upcoming eLua version will have TCP/IP
support, implemented on a MCU with 64k of RAM
<shameless_self_promotion>.
I have my doubts about the fixed allocation scheme. It will work quite
well on some applications, but I think that it's not a good idea for
the general use.

> The original Basic Stamp had 26 global variables only -- that's one way.

Indeed, but one I'm not inclined to follow at the moment :)

> It's too bad most MCUs (in the AVR/PIC style) have so much program memory and so little internal RAM.

Tell me about it!

> Has anyone run Lua with garbage collection with this kind of memory for a serious application, or does the embedded h/w developer carefully check to make sure that the app does not run out of memory?

It depends on how you define a "serious application", but I probably
never tried one. However, segregated allocators seem to handle memory
fragmentation quite well, so I think you can do garbage collection
with them (or maybe fragmentation was not your concern?)

Bogdan