Re: [avr-libc-dev] Towards a 1.2.1 release

[Bertolt Mildner]

>> A little while back someone sugested a refinement to malloc I think,
>> Did it have merrit?

> Bertolt Mildner.

> This is a bit similiar to the FP stuff.  I'd rather like to see a
> testsuite first in order to verify the assumptions made in Bertolt's
> code, like that it's really not worth spending time in figuring out a
> chunk that would fit exactly.  When I wrote the current malloc

I agree that a testsuit would be very helpful!

There seems to be a umissunderstanding.
My implementation *is* looking for a exactly fitting chunk! (At least
i hope that is what my implementation does :)

The loop stops if the end of the free list is reached *or* if a exactly
fitting chunk is found.

After the loop, "candidate" is NULL or points to the smallest chunk
that is >= len.

My implementation is (IMHO) functional equal to yours but only walks
the free list once.
That is the point i wanted to make.

BTW: I'm not at all sure that my version is faster. -> testsuite!

> implementation, I've been shocked by the simple older implementation
> that was prone to memory fragmentation, so I tried my best to avoid
> fragmentation even at the cost of a slower (and larger) malloc.  I
> think memory fragmentation in a device tight on RAM is much worth than
> a few more bytes of code.

There is a case of fragmentation that the current implementation does not 
handle:

If all chunks are too small and memory is added to the heap there may
be a free chunk at the end of the current heap.
This chunk is left unused while it could be used together with the
memory added to the heap.

But again this would mean, at last, one more walk thru the free list
...

BTW: The current implementation uses two size_t vars while only one is
needed. But i guess in this case the compiler/optimizer is taking care of that!?

Bertolt

-- 
Best regards,
 Bertolt                            mailto:address@hidden