Dragon Basement (draft)
ToFrom
DragonCore^Russ Atkinson
 CSL
SubjectDate
Dragon Basement September 21, 1984
Release as ??
Came from
 /Indigo/Dragon/Doc/DragonBasement.tioga
Last editedby Atkinson, September 21, 1984 1:10:09 pm PDT
AbstractThe Dragon Basement is a very low-level abstract machine designed to support multiple languages on Dragon. This abstract machine rests on the physical machine, and provides the following facilities: processes, monitor locks, condition variables, stack handling, virtual memory, and primitive I/O support. Most basic resources are virtualized, so each language can deal with the machine as if it owns it. These basic resources are the terminal, mouse, keyboard, disk, Ethernet, and other peripherals.
Attributes draft, technical, Dragon
The Dragon Basement
Overview
The Dragon Basement provides a base level of abstract machine that is used to virtualize dedicated resources for Dragon. We want to support multiple language environments on Dragon. These include, bu are not limited to, CedarMesa, InterLisp, and SmallTalk. Some of these environments have very strong ideas about their environments, with the common assumption being that each environment controls the machine. Each environment deals with the basement, and not with the physical machine.
Environments
Cedar, Lisp, and SmallTalk will have different conventions for managing runtime structures. Although there is a common instruction set, conventions regarding collectible storage, argument passing, and upper levels of process management will differ among the environments.
Each environment will have its own runtime data. The basic structures will be available through auxilliary registers. Other facilities will be accessible through trapping instructions.
Basement Processes and Stacks
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.
Basement Virtual Memory
We plan to support a simple page based virtual memory similar to the Cedar VM. Some environments may require certain address ranges. We are currently assuming a single address space. Some special features may be necessary for supporting non-Mesa environments, but they have not yet been identified.
The Cedar VM model deals in intervals of pages. Here is a partial overview of its operations:
Allocate: allocates a given number of pages; options may specify alignment, or restrict allocation to certain ranges of pages, or prevent intervals from crossing certain boundaries
Free: frees a given interval
Touch: causes the given interval to be swapped in (but not pinned)
Kill: causes the contents of the interval to be unpredictable, this call can reduce page traffic by indicating pages that do not need to be swapped out
Pin/Unpin: forces the given interval to be resident/swappable until the next such call, a count is kept for the number of times a page is pinned
MakeReadonly/MakeWritable: applies to an interval
Clean: writes dirty pages in the interval to the backing store
Age: makes pages in the interval more liable to be swapped out
Basement Disk
At the lowest level the Basement provides logically separate regions of the disk, with each environment assuming control of one or more regions. Operations are provided to read and write runs of pages to/from virtual memory. Each environment has its own file system.
Although it does not necessarily belong to the Basement, we should provide access to the Cedar FS level for environments that want to share files with Cedar.
It is not yet clear whether the available hardware for disks will support labels. This will affect the disk abstraction, but should not greatly perturb programs above this level of disk.
Basement Ethernet
Sending is no problem, just hand packets to the dispatcher. Presumably the packet received contains enough socket information to route it to the right handler. There will be some common routines to handle routing tables, statistics, and so forth. This needs more deign work, particularly to handle broadcast and multicast packets.
Basement Terminal
The Basement Terminal is a virtualization of the displays (color and B&W), mouse, and keyboard for the Dragon. The initial assumption is that there will only be one physical terminal for any given Dragon, although extension to more physical terminals is probably easy enough. We also assume that each programming environment will want a separate virtual terminal, although it may be possible for some environments to use the display facilities provided by other environments.
Basement Junk
Basement junk is everything that does not fit in the other categories.
Time
We need common support for time of day, condition variable timeout, and high-precision interval time. The condition variable timeout interacts intimately with the process machinery. Ideally it is also based on the hardware providing the interval timer so we do not need to base it on the display refresh.
Floating point
Our basic floating point support is 32-bit IEE standard, with the implementation being performed by hardware. The hardware is likely to support double precision IEEE floating point operations as well. At least we need to support what is in Real.df for all languages. This includes converting between real numbers and characters, common mathematical functions (trigonometric, exponential, and so forth).
Traps
The various languages will have different means for dealing with traps. The common trap handlers will simply dispatch through the trap handlers specified in the environment data.
In addition, we need a means for turning PCs into handlers for dealing with traps and signals. By examining the high bytes of the PC and examing a table kept by the loader we can determine which procedure (or module) is executing, and we can call an exception handler associated with the procedure (or module). This facility should be common, since all of the environments need something of this sort.
RPC
Some base level support is necessary for supporting transport of RPC packets through the machine when RPC is used for communicating between different environments. It is likely that we will have to support the old formats of RPC for Mesa as well as 32-bit oriented formats.