[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Using Lua in an embedded hardware environment (toward a porting guide)
- From: Ralph Hempel <rhempel@...>
- Date: Wed, 27 Dec 2006 11:45:11 -0500
I'd be really interested into a porting guide to embedded devices as
well. The main issue I had with my platform (ARM9, 256KB of available
RAM, couple MB of flash) is with memory. The GC doesn't naturally
"think" in terms of how much memory is there left. I guess I'm far from
being the first one to hack it, and some people probably did a much
better job than mine; it's a shame that this work isn't shared, e.g. on
the wiki, and I hope someone will be able to write a lua gem about it.
256K of RAM? Luxury!
I ended up using two approaches. The first was a small heap that I
allocated at link time, and then a little code to allocate more
when I needed it - which was all the time.
The second route was to specify all the RAM that Lua could use at
link time. A heap that grows is really only appropriate for a
general purpose computer where you want to minimize a program's
footprint to leave room for other stuff.
Having some statistical informations about typical memory usage would be
great as well: is it worth implementing special tricks to speed up
allocation and/or limit fragmentation on the sometimes naive memory
allocators one gets on embedded platforms? Are there some known ways to
That's a good question! I'd love to hear some opinions on fragmentation.
I notice that many blocks get allocated during parsing and then they are
reduced later. In this case, is it better to use best-fit or first fit?