lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 


On Apr 14, 2009, at 12:06 PM, Mike Pall wrote:


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.
I'll be happy to send them back regardless of whether it turns out to be suitable for these devices. There are certainly micros with more RAM. 




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.
We're currently able to start up the interpreter in about 5-6k of SRAM, in large part through some patches that Bogdan Marinescu developed to keep some things in flash that would otherwise get loaded into RAM. That said, we're certainly not expecting miracles in terms of RAM usage, most applications that one would run on eLua are fairly compact in terms of memory usage.
I did also try applying the RVM patch, but it didn't apply cleanly and the fixes seemed non-obvious at first glance. I'm pretty sure I could figure them all out, but it was going to take more time, and so I shelved it for the moment. 




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.
Hmm.. fair enough. I'm pretty sure that's what I've done in more than a few cases when experimenting with going below 1k, and that I was getting lucky with that :-) 



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).
Those are helpful pointers, I suppose I'll have to think about this a little and maybe do some checking on the newlib functions we're using. For one part, I do know that we are using a rather small BUFSIZ of 256 for Newlib. 



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.
Good point. What about situations where you have control over what the coroutine consists of. One model we're thinking of is using this to deal with hardware events (button presses, changes in ADC signal level, etc..). We could, I suppose, potentially make the coco routines a special class that could be used but not modified and could provide certain facilities like the event handling. In these cases I presume we could know by static analysis how much those coroutines would use?
In terms of figuring out how much stack space should be allocated, if the coco routine is written in Lua, is stack usage comparable to the growth one might see for the main lua stack if that were just implemented as a function? I'm guessing that if I were using print functions in lua and I created a coroutine that also printed that the coroutine's stack would have to contain a duplicate buffer. 




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.


OK, that makes sense.
Thanks for the information. Your responses have been quite helpful in thinking about what to do/use in this context. 

Best.

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder@fanplastic.org
http://fanplastic.org/key.txt
ph: (847) 448-0386

Attachment: PGP.sig
Description: This is a digitally signed message part