I think it's good you've found a way to automatically set up the heap by default -- lots of people just want things to work out of the box but you can't really do that for a lot of situations on a small memory machine. I am moving more toward declarations of code and data segments and will probably do that for a default heap segment too.
There is a new version of malloc percolating that improves performance and adds a whole lot more besides. Part of the algorithm is similar to sdcc's allocator which allows O(1) realloc and free. This was one thing I wanted to revisit since some library functions needed to do realloc to accommodate incoming characters from a stream. So it's going to be:
(1) Again, support for multiple heaps; I think this is very important and z88dk's allocator is the only one that has this:
* different threads can have their own heaps so no lock is required to allocate memory (there are multithreading z80 systems out there!)
* different memory configurations can have their own heap so you can manage near memory allocation on bankswitched machines.
* different heaps can hold different kinds of memory. For example, the zx81 cannot execute code out of some memory areas so you could have one heap to allocate memory from a region that can execute code and another to allocate from a region that cannot.
(2) Again, any number of disjoint memory blocks can be added to a heap.
This allows scattered bits of available ram from around the memory map to be added to the heap
(3) New: allocate memory at a fixed address
You can request a memory allocation from a fixed address. It is not uncommon that a program needs to have memory at a specific address. Of course you're more likely to succeed in getting the block if the request is made at the start of the program.
(4) New: allocate memory from the largest available block in the heap
This would be done when the block will be constantly realloced to expand size as the program runs. By starting with the largest available block, the number of memory moves caused by realloc will be minimized, and likely zero if other memory is not freed while the realloc is going on. The new realloc algorithm is very fast when a memory block can be expanded in place.
(5) New: allocate aligned memory block
You can specify that the start address of the block needs to be aligned to some power of 2. So, eg, if you need a block of memory aligned on a 256-byte boundary for a table, you can now request one.
The allocation algorithm is still first fit currently but I have been thinking about first fit with hint where the hint would be a block following the one last allocated. Normally with a first fit algorithm you start at the beginning of the heap and linearly search for an empty spot big enough to hold it. The current z88dk implementation only holds a list of free blocks so this is not a problem. However this new implementation that allows O(1) realloc is similar to sdcc where you also traverse blocks that have already been allocated. So, if you've made 30 allocations (and no frees so that the allocations are adjacent) the first fit algorithm is searching fruitlessly through 30 blocks in the heap without any space available. This is potentially quite slow. The hint would tell the allocator to start search from the last block allocated rather than from the beginning of the heap each time.
I've been waffling on this since it would make malloc faster and I could make sure realloc hangs onto a large block for longer. But I'm not sure on such a small memory machine if there would be a lot of allocated blocks to search through. More importantly, I'm thinking the hint algorithm might lead to much worse fragmentation issues since it would distribute allocations throughout the heap's memory space. I don't know if you guys have any thoughts on that?
Anyway there are other means of memory allocation too. The balloc library is the very fast block memory allocator for small fixed size memory blocks. One byte overhead per block and no fragmentation if you can stick to fixed sizes.
There is also a compacted memory allocator coming up that will be used for environment variables. This one you provide a fixed memory space and you can add and remove items from it. The pointers and items themselves are stored in the block, with the data automatically moved around to keep allocations compacted. Out of block pointers can also be added (this is required by some environment C functions) which reference data outside the block that is not managed by the block. The overhead is two bytes per block for a pointer. Freeing would be slower as the block needs to be kept compacted but there is no fragmentation.
I'm not sure if the malloc+hint is worthwhile given the potential fragmentation problem and other options.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev