Interrupt and multicore safe allocator

[Uthedris]

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.

[mattnite]

This is really great, but an allocator is going to need unit tests, just a few for this PR and we can follow up later as well.

[Uthedris]

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.

[Uthedris]

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.

[Grazfather]

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.

[Uthedris]

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.

[Uthedris]

There is an example program in examples/raspberrypi/rp2xxx/src/allocator.zig that tests the allocator.

[mattnite]

Could we have some unit tests that run on a host?

And do we really want to make a global heap in the linkerscript? Why not just make a static buffer?

[Uthedris]

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.

[mattnite]

Good point, in that case we are good to go, just fix the conflicts and then we're good to go!

[mattnite]

@Uthedris ping, there are conflicts still