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.
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
As we are now allocating stack memory at absolute addresses, we use
Processes.InitRaw to set up process
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.
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.
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