On Wednesday 08 July 2009 02:58:42 Peter Tyser wrote:
Robin Getz wrote:
On Wed 8 Jul 2009 01:58, Mike Frysinger pondered:
On Tuesday 07 July 2009 18:24:56 Kumar Gala wrote:
On Jul 7, 2009, at 3:25 PM, Scott Wood wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 15:02 Tue 07 Jul , Scott Wood wrote: > Kumar Gala wrote: >> Those would help if the data structs had gotten bigger. In this >> case the code itself is just larger. > > Perhaps we should look into using/writing a malloc implementation > that takes a space/speed tradeoff more in line with U-boot's > requirements (using a simple first-fit linear scan of free blocks, > for example) -- and hopefully more readable than dlmalloc? > > I nominate those with the tightest space requirements to do > this. :-)
I agree it's sound a better plan but I'll take a lot's of time
Do we think there is some other project that we can acquire one from?
there was another public domain malloc implementation Robin pointed me to recently, but i cant seem to remember/find it.
It was bget
The CFE bootloader has a pretty simple malloc implementation. It looks relatively readable and is much smaller than dlmalloc:
ptyser@petert cfe$ size cfe30/lib_malloc.o text data bss dec hex filename 1128 4 0 1132 46c cfe30/lib_malloc.o
http://www.broadcom.com/support/communications_processors/downloads.php
Some other liberally licensed bootloaders such as PMON2000 might have some basic implementations too.
it's trivial to find smaller implementations. i guess the problem we have is that we dont have any guidelines for what we want out of a malloc implementation. i would bet that dlmalloc fairs better than these simple implementations wrt fragmentation, re-use, and freeing. but if our typical u- boot usage does little malloc/free, then this better behavior doesnt really matter to us.
does dlmalloc have any compile time knobs to help direct the functionality actually desired ? -mike