Dragon Basement processes are virtualized processors. Each process has its own stack of frames, where each frame corresonds to the control and data associated with a procedure call. The Basement provides for process creation, termination, and scheduling.
Processes
A process can only be running on a single processor at a time, but can be run on any processor. Unlike PrincOps machines, processes can be running with true concurrency when there are multiple processors.
The scheduler associates processes with proecessors. A process becomes associated with a processor when a processor is available and a process is ready. A processor becomes available when the process it is executing waits for a condition variable, a monitor lock, a page fault, or when its time slice expires. The scheduler also turns I/O (and timer) interrupts into condition variable notifications. The process machinery turns I/O (and timer) interrupts into condition variable notifications.
Each process will be associated with a particular environment. The base pointers into the environment will be switched at process switch. When a processor switches from one process to another, the former process is saved, and the latter process is restored. Process saving involves storing the state in the EU stack registers into memory, and also saving some of the constant and auxiliiary registers to the process control block. Process restoring does not include restore the EU stack, since that will happen dynamically as the process performs procedure returns. Process restoring does include restoring those constant and auxilliary registers previously saved, and loading those registers associated with the environment.
A small number of priority levels are provided to distinguish processes that are more important from those that are less important. The scheduler runs higher priority processes in preference to lower priority processes. However, unlike PrincOps, there is no guarantee that a high priority process will preempt a low priority process, even when both are equally ready to run.
If InterLisp and SmallTalk retain their current notions of process, they will build thier processes on top of Basement processes. Mesa processes will be equivalent to Basement processes.
The primitive locking facilities will be essentially the same as those in Mesa. That is, there are condition variables and monitor locks, where condition variables are protected by monitor locks (except for those associated with interrupts). The primitives will be Entry and Exit for monitor locks, and Wait, Notify, and Broadcast for condition variables. In addition, there is Yield, which will force entry to the scheduler (and can be used to yield cycles to a designated process).
Stacks
The stack for each process is conceptually a linked list of frames (a.k.a. activation records), with the more recently created frames liked to the less recently created frames. Each frame exists in two parts, volatile and stable. The volatile part is stored in registers while that frame is most recent in the stack and the process is running (associated with a processor), is stored in resident virtual memory (save blocks) when the process is not running or when a more recent frame for that process is in memory, and may be either in registers or save blocks when the process is running, but the frame is not most recent. The stable part is always in normal virtual memory (not necessarily resident). The compiler is responsible for the distinction between volatile and stable parts of a frame.
The stack machinery includes the provision of Alloc and Free for save blocks and the stable parts of frames. To support stack tracing for Cedar garbage coollection we will also be able to quickly enumerate the save blocks and stable parts of processes.