Re: [avr-gcc-list] Struct problem

[Erik Christiansen]

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.