Re: [avr-gcc-list] Struct problem

[David Brown]

>As "David Brown" <address@hidden> wrote:

>>Basically, standard malloc() / free() implementations can (unless you
>>are very careful, or have particular paterns of usage - such as only
>>allocating at program startup, and never freeing since your program
>>never ends (in which case, why are you using dynamic memory in the
>>first place?)) have

>In that case, I'd indeed suggest writing your own malloc() anyway. ;-)
>It might make sense e. g. to not use the standard malloc() in such a
>situation when you want to use stdio with the current implementation.
>The librarie's malloc() jumps through through hoops to avoid memory
>fragmentation, which of course, costs a lot of code -- that is not
>needed at all if you never free it again.

>>problems such as memory fragmentation, varying delays when allocating
>>memory, failed allocations, memory overheads, etc.  It is frequently
better
>>to have memory pools for allocation of specifically-size elements, or
other
>>specific code.

>I agree that using various pools might be more better (and thus a good
>reason to write your own replacement) for some usage patterns,
>although I guess the code will be even more bloated for that (which is
>the main reason why I didn't use a pool-based allocator.)  I don't see
>how you're going to solve in particular the problem of failed
>allocations by just writing your own. ;-)  (Sure, avoiding malloc() is
>the only solution to that.)
>--
>J"org Wunsch        Unix support engineer
>address@hidden
http://www.interface-systems.de/~j/

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.