Question

I have to use c/asm to create a memory management system since malloc/free don’t yet exist. I need to have malloc/free!

I was thinking of using the memory stack as the space for the memory, but this would fail because when the stack pointer shrinks, ugly things happen with the allocated space.

1) Where would memory be allocated? If I place it randomly in the middle of the Heap/Stack and the Heap/Stack expands, there will be conflicts with allocated space!

12 What Is the simplest/cleanest solution for memory management? These are the only options I’ve researched:

• A memory stack where malloc grows the stack and free(p) shrinks the stack by shifting [p..stack_pointer] (this would invalidate the shifted memory addresses though…).
• A linked list (Memory Pool) with a variable-size chunk of memory. However I don’t know where to place this in memory… should the linked list be a “global” variable, or “static”?

Thanks!

Answer 1

For embedded systems the memory is partitioned at link time into several sections or pools, i.e.:
ro (code + constants)
rw (heap)
zi (zero initialised memory for static variables)

You could add a 4th section in the linker configuration files that would effectively allocate a space in the memory map for dynamic allocations.

However once you have created the raw storage for dynamic memory then you need to understand how many, how large and how frequent the dynamic allocations will occur. From this you can build a picture of how the memory will fragment over time.

Typically an application that is running OS free will not use dynamic memory as you don’t want to have to deal with the consequences of malloc failing. If at all possible the better solution is design to avoid it. If this is not at all possible try and simplify the dynamic behaviour using a few large structures that have the data pre-allocated before anything needs to use it.

For example say that you have an application that processes 10bytes of data whilst receiving the next 10 bytes of data to process, you could implement a simple buffering solution. The driver will always be requesting buffers of the same size and there would be a need for 3 buffers. Adding a little meta data to a structure:

{
    int inUse;
    char data[10];
}

You could take an array of three of theses structures (remembering to initialise inUse to 0 and flick between [0] and [1], with [2] reserved for the situations when a few too many interrupts occur and the next buffer is required buffer one is freed (the need for the 3rd buffer). The alloc algorithm would on need to check for the first buffer !inUse and return a pointer to data. The free would merely need to change inUse back to 0.

Depending on the amount of available RAM and machine (physical / virtual addressing) that you’re using there are lots of possible algorithms, but the more complex the algorithm the longer the allocations could take.