Process Stacks


Each process requires its own stack, which is usually declared directly in the module that implements the process:

CONST StackSize = 1024;
VAR stack: ARRAY StackSize OF BYTE;

Processes.Init will then set up the stack for the underlying coroutine, which works on absolute addresses.

PROCEDURE Init*(p: Process; code: ProcCode; stack: ARRAY OF BYTE; stackHotSize, ptype, prio: INTEGER; id: ARRAY OF CHAR);

The Initial Stack

When the Oberon system starts, it does not have yet any notion of processes, and uses the stack area as defined via the boot loader and module Kernel for the start-up sequence. In EO, this stack is the only one ever needed and used, in order to execute commands and tasks.

This initial stack is located between the top of the module memory and the bottom of the heap space.

Stack Reallocation

At first sight, after system start-up, in Oberon RTS this initial stack could in principle be reclaimed and used as module memory, or even as heap space. As we need a stack for command execution anyway, a simpler solution was chosen, which does not require any changes to the Inner Core, and leaves the overall memory layout unchanged and compliant with EO and Project Oberon.

After the system start-up is completed, before control is handed over to the scheduler, the initial stack is allocated as follows:

  • the top section of the main stack is allocated to the scheduler coroutine
  • the stack area below the scheduler stack is allocated to process cmd

As we are now allocating stack memory at absolute addresses, we use Processes.InitRaw to set up process cmd:

PROCEDURE InitRaw*(p: Process; code: ProcCode; stackAddr, stackSize, stackHotSize, ptype, prio: INTEGER; id: ARRAY OF CHAR);

This solution allocates close to the same stack space to handling commands and uploads as it would in EO. The scheduler only needs 512 bytes of stack space.

Other Processes

Processes.InitRaw could in principle be used for any control process, for example to implement a different stack scheme, where all process stacks are kept in a contiguous memory space, in lieu of distributing them across the corresponding modules.

Using SYSTEM.ADR it would be possible to only have Processes.InitRaw, and omit Processes.Init from the API. However, application-level control processes should not require to use SYSTEM.