RE: [avr-libc-dev] Malloc implementation in avr

[Stu Bell]

> > > Or he may want to write his own free().
> > 
> > He is not allowed to do this (the C standards explicitly 
> > forbids that an application overrides a library implementation), 
> > and this would not work in almost /any/ C environment, because 
> > the way free() must be implemented is completely tied to the
> > implementation of malloc() itself.
> 
> 
> This sure explains the rationale. Thanks for the details.

On the other hand, this should not stop you from implementing your own
memory manager if you believe you understand your application's needs
and usage patterns, and you believe that a better mechanism for the
application would improve it's memory usage.  

For example, FreeRTOS comes with 3 different "heap managers" (or
malloc/free pairs) with different ideas about how dynamic memory should
be managed.  In each case, the heap manager is pre-allocated a chunk of
RAM that it manages.  In our application, we've taken one of the heap
managers and tweaked it further as we've seen how memory is actually
used.

Rather than calling the routines "malloc" and "free", the routines are
called "pvPortMalloc()" and "vPortFree()".  From a strict maintenance
point of view, I prefer to have a specially named function for my heap
manager instead of renaming malloc() and free().  This will tell a later
programmer that he is not looking at the "box standard" malloc but at a
custom heap manager.

In the embedded world, the programmer can and must control many things
that are handed to him in the "big compute" world of PCs.  Memory
management is one of those things.  Realize that, while the C compiler
and library are the enablers, *you* must decide how to manage the
resources available to you.  That is the blessing and curse of
programming microcontrollers.

Best regards, 

Stu Bell 
DataPlay (DPHI, Inc.)