Re: Lua+Coco on Tiny Devices

[Mike Pall <mikelu-0904@...>]

James Snyder wrote:
> I've recently been working on making Coco work with eLua 
> (http://eluaproject.net), and I've managed to get the patching approach 
> to work for setjmp as provided by newlib.  I'll be happy to contribute 
> back the changes for this when they're a little more polished and I've 
> had a chance to test them more.

Please do. Patches for better target support are always welcome.

> The first thing I noticed is that the default stack size pretty much  
> exceeded the available memory on the device I was using (64k SRAM  
> total).

Well, 64K is just barely enough to run some mini apps with plain
Lua. Coco requires additional memory for the C stacks of every
coroutine. There are other workarounds for the issues Coco solves
(e.g. yielding across pcall). Of course these workarounds may not
be as convenient or as complete as Coco, but may be more suitable
given your constraints.

> I was able to pare it back to about 1k and get all of the test  
> scripts running with reduced numbers of coroutines.  When I try going  
> lower than this further (to, say, 512 or 256 bytes), though, it blows  
> up.  I'm not familiar enough with Lua itself or with coco to know what  
> to expect in terms of necessary stack space, but I was wondering if  
> anyone had any thoughts on this.

Umm, you're playing a bit of Russian Roulette here. Since your
device doesn't have an MMU, you'll only notice a stack overflow
because some unrelated part of memory gets corrupted. Of course
this can happen with the main C stack, too.

It's hard to determine the absolute minimum amount of C stack
space needed by your app. You need to find the worst offenders and
round up generously:
- Most of the string.* functions need at least BUFSIZ bytes
  (usually 4K or 8K).
- The Lua parser may need quite a bit of stack space depending on
  the maximum syntactic nesting level.
- Some functions from the C library can be surprisingly expensive
  in terms of C stack space usage (e.g. gethostbyname).

I don't think you can go significantly below 16K without having
complete control over _all_ of the code ever run by your app.

Dedicating a quarter of your RAM for a single coroutine doesn't
sound like a good deal. That's why I said above that Coco is
probably not the best solution for a low memory environment.

> When the coroutines are created in the 
> example scripts, what exactly is needing to be preserved on the stack?  
> Can this be pared back at the cost of performance?

Everything that's live on a C stack needs to be preserved.

> Also, could one 
> safely allocate stack space only as needed by actual stack size as 
> opposed to pre-allocation?

Nope, C stacks cannot be relocated easily. The C compiler is free
to store pointers (i.e. absolute addresses) to other parts of the
same stack in there. Alternative layouts (e.g. linked stacks) are
rarely supported by C compilers.

--Mike