Memory management in ACORN 1.2

Memory management in ACORN. 
ACORN kernel from the very beginning was planned to work within a small  RAM Memory environment so the presumption is - RAM is a scarce resource! Organizing the RAM efficiently is of vital importance as to how many tasks could be scheduled and how much system code like synchronization primitives and system structures we could reserve in it.
Multi threading is achieved  by assigning a stack space for each task during the MCU initialization, which will store the task register context as well as  the values of stack related instructions like push,call,rcall,icall(check the instruction set) during the task’s code execution. It is important to understand that in such system stack overrun is very likely to happen if the CALL(accounts for PC register saved on current task stack) instruction is used recursively - one procedure calls another which calls another and so on...

Interrupt calls(accounts for PC register saved on arbitrary task stack) and system synchronization also should be taken into account as they happen in an arbitrary context(whichever task happened to run) .We may eventually implement a system stack space in XMEGA processors where RAM is plenty but as i said in the beginning, the current kernel design is for small RAM devices and system stack is out of question.
RAM space fragmentation.



It is evident that the more tasks are added to the system less ram area for global variables is left.
Each task stores the complete register set of 32 general registers + SREG + Program Counter value which accounts for 35 RAM bytes of bare memory minimum for each task.When calculating the total RAM space per task, the rule that nested interrupts are not possible(yes, don’t enable the interrupts during interrupt handler processing ) , should make the calculation easier.


TCB structure.
Task Control Block is system RAM structure that identifies and describes the execution of a single task.It consists of 4 bytes.Tasks are static -TCB structure per task is created during the CPU reset and never deleted off the RAM.


{1-2}2 bytes address of the stack position where the task left off its execution due to a time quantum expiration  or task voluntarily relinquishing it.
{3}  task control bits
S bit - task’s schedule ability bit.{0 - task is schedule able(default);1 - task is not schedule able}
P bit - task’s priority bit.{0 - NORMAL priority;1 - DEVICE priority}
{4} timeout units for the sleep macro.
Synchronization structure.
All synchronization mechanism currently in existence - basic event,extended event,mutex and barrier reserve yet other chunks of memory. Probably more tasks’s concurrency structures will be added later on since acorn is an adventurous endeavor in single as well as multi CPU processing. It is important to know that synchronization macros use push and pop commands to free registers for their own usage which needs to be taken into consideration when the tasks memory usage is caculated.

There will be plenty of articles on synchronization in the “Kernel unleashed” area. This structure may eventually change due to optimisations.




Beware that interrupts happen in an arbitrary context(which task will be current when interrupt happens is not known) so any register that is used within the interrupt handler MUST be saved on the current task stack prior to its usage! There are two scenarious to handle an interrupt event.


  • Use Interrupt Dispatching to an interrupt dedicated task - the interrupt is dispatched for processing in a dedicated task context which will run at DEVICE level. It takes some CPU time to deschedual the processor and switch the dedicated task from suspended to running state.
  • Processing interrupt within the very interrupt handler routine - the interrupt is processed in its handler in an arbitrary task context.It is the fastest response to the interrupt source but reqiues stack usage of the current task, which is a bit dangerous as stack depletion is possible if many registers are used(saved on current arbitrary stack). 


Rule #1 must be included before any other file in the main entry Kernel.asm file in order to have the same RAM fragmentation as the one on the figure above.


Thougts for the future

I am planning AcornVerifier program which, when run, will check and calculate the integrity of the RAM layout.