Re: [avr-gcc-list] malloc/free uses much more flash memory

[Joerg Wunsch]

Klaus Rudolph <address@hidden> wrote:

> the actual malloc/free use a lot more memory in flash.

Well, i mentioned it here when introducing the rewritten version.
It's the new free() that consumes more memory since it does a lot more
work.  The old free() simply cleared a bit in the memory block, and
then returned.  The bloat is a bit more than 200 bytes, while malloc()
itself even got a little smaller (which quite surprised me).

> What's the advantage of the new malloc/free and

I also wrote about this here when introducing it. :-)

Basically, the first version of malloc() did only a very simple job
that was guaranteeing memory fragmentation in all cases where you was
allocating and deallocating blocks of different size.  Only in case
your application was always allocating blocks of the same size, it
could survive without eventually eating up all memory.  (This happened
because by the first time you allocated a block, its size was ``set
into stone''.  free() only cleared the `block in use' bit then, and
the block was awaiting its reuse by a request of exactly the same
size.  If no such block had been found for another request, an new one
was to be allocated.)

> is it possible to use the older (smaller) ones
> with a (compiler) switch?

Of course not.  Think about it: malloc() and free() are located in the
library (already compiled long before).  How would a compiler switch
change them?

What you can do is to use the old malloc.c file together with your own
files, and compile and link it from the compiler's command line
(resp. from within your Makefile).  This will make the linker use the
definitions of malloc() and free() from your file, and not touch the
library version.

If there's sufficient demand for also maintaining the simple version,
we could perhaps persuade Marek to also put that file into the
library, by renaming the entry points to something like simplemalloc()
and simplefree().

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/
avr-gcc-list at http://avr1.org