If you are targeting an existing OS, malloc/free can be simple wrappers to OS syscalls for memory allocation. Not very efficient, but pretty straightforward to implement.
If targeting direct hardware, any CS student should have learned how to implement a memory allocator on their compiler design, data structures or OS classes.
Back when I graduated, this would be a home work exercise.
If you want to implement a high performance memory allocator that works under pressure in a multi-core context, then yes it is complex to implement.
Now something that allocates/releases memory with a general purpose algorithm? That is quite simple and many compiler design books even provide such examples.
> If you are targeting an existing OS, malloc/free can be simple wrappers to OS syscalls for memory allocation.
Not really, there's no such thing as malloc/free syscalls. On Linux, you have mmap/munmap (at page granularity) and brk/sbrk (which only extend the current heap). You could implement malloc as either a mmap() of one or more pages, or by using sbrk() to extend the heap by exactly the memory you need, but then freeing that memory becomes much harder.
> Should I write a full tutorial on an HN post how to write memory allocators when anyone can easily search for one?
No, but a memory allocator is more that "simple wrappers".
My point was that OS kernels (Linux/BSDs at least) don't actually provide malloc/free as syscalls, and that you need to implement an allocator in userspace if you want these functions (even if it's a trivial allocator that wastes memory).
malloc/free are part of the C language runtime, not OS syscalls.
A compiler writer can build the memory allocator on top of what the OS provides as syscalls or take a shortcut and use the C runtime library instead while adding a dependency to it.
