ZigEmbeddedGroup
Interrupt and multicore safe allocator
This PR supplies an implementation of a std.mem.Allocator.
It can be use to allocate memory from a specified buffer, or from the otherwise unused ram that follows the .bss section.
Unlike std.heap.FixedBufferAllocator it supports re-use of freed memory, coalescing adjacent freed blocks to lessen fragmentation.
It can be safely used from multiple cores or from an interrupt service routine.
It has been tested on RP2040, RP2350 (both amd and riscv) and on an esp-c3.
I have a test suit that I used. ~~Is there someplace where I should put it in the microzig directory?~~ I'll move it into the test directory.
Looking closer, I'm not sure how to proceed with adding tests. ~~I'm adding a zig test case to the allocator itself. That would run on the machine doing the compilation, but should validate the allocator itself.~~ Do you also want some sort of test program to run under microzig on the microcontrollers. I'd guess that would go in the test direcory, but I'm unsure of the details of how I should do that.
I don't think we have a place for that now, but we do want to get HIL testing in place, so at the very least I'd say hold on to it. We could commit here, but I'd be afraid it would bit rot with nothing running it.
OK. I'm planning on using it for some stuff I'm doing, but I can just use my fork of microzig for that. I'll keep the PR open, and when there is a plan for building tests I'll add what's needed.
There is an example program in examples/raspberrypi/rp2xxx/src/allocator.zig that tests the allocator.
If by "run on a host," you mean to run on the machine where the code is compiled, the problem is that the mutex code suspends interrupts and, since that accesses harware registers, those routines won't compile on the host. I suppose I could do some comptime magick to exclude the mutex from the host build, but that would prevent testing allocation from different exectuion threads.
The code does allow accessing from a static buffer, it also has a function to make such a buffer from the remaining heap. On a lot of systems I've used that was standard practice, the stack grows down from the top of the heap and dynamic allocations grow up from the bottom. It just seemed reasonable provide a method to be able to use whatever memory a particular chip had avaiable.
Good point, in that case we are good to go, just fix the conflicts and then we're good to go!
@Uthedris this is looking good. If you can just add a few unit tests for the allocator then this should be good to go.