Re: [avr-gcc-list] Struct problem

[Simon Han]

On Wed, 4 Feb 2004, Erik Christiansen wrote:

> On Tue, Feb 03, 2004 at 09:19:10AM +0100, David Brown wrote:
> > Using your own allocator is not going to create more memory on the chip,
> > unfortunately :-(  However, if you are suffering from memory fragmentation
> > (i.e., the free memory exists, but is in too small chunks to be useful), or
> > if there is too much overhead (I have not looked at the avrlibc
> > implementation to know this) then it is possible to have more usable memory
> > with a specially-written allocator.  Of course, it all depends on the
> > requirements - including the time taken to write and test the code.
>
> Having always avoided malloc, because of temporally non-deterministic
> behaviour, and fragmentation concerns, I've usually written a simple
> block allocator. Making all allocations fixed size ensures that the
> first available block is always usable, so no searching. It is never
> broken down, so no fragmentation.
>
> Where block sizes several binary orders apart were required, two sizes
> have sufficed so far, allocated from separate pools. A demand-based
> movable boundary could sometimes help avoid starvation adjacent to
> plenty, but I have not needed that yet.
>
> The thought of using malloc in 4K of total RAM is scary, but then, that
> very limit could lead to desperation, I'll admit.
>
> Erik
>
> --
>  _,-_|\    Erik Christiansen                    Phone: +61 3 9264 3416
> /      \   Research & Development Division        Fax: +61 3 9264 3438
> \_,-.__/   Voice Products Department
>       v    NEC Business Solutions Pty. Ltd.
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list
>

Sounds a wonderful tool.
Is it open source?  :-)
Can I get a copy?

Thanks,
Simon