The Domain's Role
The most common action of a domain is to execute instructions found in the domain's address segment. These actions only change the domain and the domain's address segment, if the instruction specifies storing.
Other actions are to send messages, typically to other domains. This can occur upon explicit instructions of the program, or upon exceptional circumstances such as invalid instructions in the programs or references to invalid portions of segments. See (trap) for details on this.
There are three classes or types of keys under discussion here: They are called (_domain), (_start) and (_resume). Each key of these types designates a node. When viewed in the context of one of these keys, a node is called a (_domain root). This section is about the structure and interpretation of domain roots.
A well-formed domain root contains keys that designate two other nodes. Together these three nodes are called a (_domain). There is nothing in the nodes that specifically identifies them as part of a domain; when we speak of a domain we are attaching an interpretation to a set of three nodes, and we are presuming the nodes, viewed as a domain, are well-formed.
In the level of description which excludes the domain-tool key {(p2,mkdomk)}, it is possible to view a domain as an indivisible object. We will often take such a view, even in this section. This level of description is useful because few programs hold domain-tool keys.
Domain creators {(p2,dc)} are generally available that will return a domain key to a new domain {a domain composed of new nodes}.
See (p3,domprgnotes) for some programming notes about domains.
There is no explicit test for a process in a domain.
During a gate jump a process may disappear from one domain and a process may appear in another. We sometimes speak as if this were the same process; we say this because normally the new process will start running in less than a millisecond after the old process disappears.
Every action that takes place in Gnosis takes place as a result of a domain with a process. We say a domain with a process takes action, or executes, or runs. The kernel considers one or more of the domains with processes at a time and runs them. What order the kernel runs them in, and for how long at a time, is up to the kernel {except, perhaps, for (p1,priority)}.
Evolution of the Logical State of the System
A jump, whereby arguments are copied and processes may be created, destroyed or merely moved to another node.
On a disk queue awaiting a page or node which is necessary for the next action that the semantics of the domain indicates
Awaiting the readiness of a domain that it is attempting to jump to with a start key.
See (kernel-logic,scheduler) for how the kernel chooses which domain to give the CPU to. See (priority) for another proposal.
A node is (_well-formed as a domain) iff:
{2} PER in C4 is off or C7 thru C9 are data keys, and
{3} slots 14 and 15 of the domain root do hold node keys, and
{4} the three nodes of the domain are distinct, and
{5} all slots of the general regs node holds data keys, and
{6} slot 13 of the domain root holds either DK(0) or DK(1), and
(The two clauses below might be deleted in the future. This change isn't implemented yet. See (jumpvalid) and (bigia).)
{8} bits 8 thru 17 of C4 are either 00 or 03, and
{10} (bit 8 (S) of the PSW is zero or (For some n < 256 C10 holds DK(n) and For some m < 65536 C11 holds DK(m) and
{11} the high-order bit of the 7 bytes of data in the data key in C12 is 0.
{arcane}See (p3,one-node-dom) for a use of malformed domains.
Design Note: We should define as mal-formed, any domain with KVMA on and a non-zero AND of the pending interrupt mask with the system mask, and then reclaim the bit allocated in the trap code described at (ioint).
The following terms have been imported from POP:
If the domain is allowed to invoke keys {(p1,invoke-permit)}, the key registers are controlled directly by the program in the domain. If it is not allowed to invoke keys, the key registers are inaccessible to the program.
As the process in the domain changes the general and floating registers, these data key values change. But this operation is optimized {the values are cached} so the domain executes instructions that change registers at the full execution speed of the underlying hardware.
Bytes in one of these data key values other than the right 6 bytes do not affect the registers and vice versa.
If P is one then C7 thru C9 will control the PER hardware. See (p1,per).
If S is one then C11 is effective and certain privileged instruction codes of the 370 are simulated by the kernel. See (sm) for details.
CC is the condition code.
MMMM is the program mask.
LL is 11 if SVC 253, 254, and 255 are to be interpreted as key invocations and 00 otherwise.
"A" represents 24 bits of instruction address.
C3 is the root of the memory tree. See (p1,memtree). It is a memory key.
C13 holds DK(0) while the domain is available and holds DK(1) while it is busy. See (p1,dsterm) and (p1,malform).
Trapping
C6 must be a data key. The low-order 32 bits of the data serve the function of control register 8. The rest of the data is reserved and should be zero.
Note that the current 370 hardware only uses the low-order 16 bits of control register 8 to designate monitor classes. {See (p1,monitor).}
When a PER event occurs, C9 receives a data key. The low 6 bytes of the data contain, in the high 2 bytes, the PER code {returned in locations 150 and 151 by the hardware} and, in the low 4 bytes, the PER address {returned in real locations 152 thru 155 by the hardware}. {The rest of the data key is unspecified.}
The PER facilities as they appear to the Gnosis user are transformed somewhat from how they are described in POP. A program event detected in the execution of an instruction causes the setting of the PER bit in the trap code only once per {conceptual} execution of the instruction. This setting of the trap code occurs after the event has occurred and before any new instruction in that domain has started. {It may occur before the end of the execution of the instruction that produced the event.} If the domain key holder sets C9 to DK(0) every time that the trap code is set, then C9 will always describe just those program events that have not yet caused the setting of the trap code.
The instruction-fetch event becomes an instruction conclusion event -- it is reported only when the instruction concludes or when it has caused the trap code to be set. Thus an MVCL may cause a trap code setting for a storage alteration event and later cause another trap code setting for the "instruction fetch".
PER and Key Jumps
For purposes of program event recording, an explicit key invocation is treated as an instruction. The instruction-fetch event will occur at the end of the instruction just as if the SVC had been an ordinary instruction. If a register is modified and the register is being monitored for modification, the register-modification event will occur. {Fork jumps do not modify registers.}
Implicit calls do not cause PER events.
Key invocations do not cause successful-branch events.
When the parameter string of the jumpee is specified by its virtual address, a storage-alteration event may occur in the jumpee. The event will occur just if some portion of the parameter string is being monitored for alteration.
When a jump is made to a start or return key and the PER bit in the jumpee's PSW is on, then C9 is assumed to be set up as above. If the register-modification event occurs, the appropriate bit is or'ed into C9. Then, if any PER events are indicated in C9, the bit indicating PER is or'd into the jumpee's trap code.
If KVMA is in effect then C10 holds the (_pending interrupts) which will cause a trap if an emulated instruction should introduce a system mask into the virtual PSW with bits that correspond to one bits in the pending interrupt mask.
C11 does not influence the process in the domain unless KVMA is in effect {bit 8 of C4 is one}. In this case C11 must be a data key or the domain will be mal-formed. The right two bytes of the data key in C11 form the left two bytes of the "virtual" BC mode PSW. See (sm) concerning the significance of these fields.
While in the house the workman faithfully obeys instructions that are part of the house. If certain tools are lacking in this house the workman may have to visit another house {call another domain}. He must have a key to the new house which he might have brought with him originally or, more likely, have found in the current house. He leaves the current house via the back door, leaving the front door bolted and the back door locked {leaves the domain in the "waiting" state}. The front door must remain bolted because the workman has his job setup, which must not be disturbed. In the process of leaving, a key magically appears that will enable him to return thru the back door. {An return key will be produced that permits any holder of that key to reenter the domain.}
The workman {or another with the same return key} subsequently returns thru the back door {reenters the domain with the return key, and the domain becomes running again.} During this time the front door remains bolted {domain busy}; any other workman trying to enter will wait at the front door until it is unbolted. As the first workman leaves he may take with him information or keys that he had access to while in the house, but remember that he is faithfully obeying the instructions of the house. As he leaves he unbolts the front door. {The domain becomes available.} He does not notice the other workman who quickly enters the house and bolts the door.
Sometimes something happens to the domain that is not supposed to concern the logic of the program in the domain. An example of this is a page fault in a segment that another domain is responsible for mending. Another example is a decision by some scheduling authority that the program should be suspended for a while in order to share resources. Another type of blockage is due to a program interrupt that is due to the logic of the program but that is typically unanticipated by the program. An exponent overflow is an example of this. In all these cases the domain executes an implicit jump and enters the waiting state.
A well-formed domain is in exactly one of three states:
The term (_busy) means not available, i.e., running or waiting. {A domain is (_busy) iff C13 holds DK(1).}
If the domain's meter is valid {(vmeter)} or its trap code begins with X'0500000001' {the code for meter traps}:
SC=10 The meter node has invalid format.
SC=14 The meter level is greater than 20.
SC=16 There is a permanent I/O error accessing one of the meter nodes.
The KVMA mode speeds up this function. When bit 8 of the PSW is one, the right two bytes of the data key in C11 of the domain model the left two bytes of the 370 privileged mode PSW. Privileged instructions that sense and modify the system mask may be thus directly interpreted by the kernel. The interpreted instructions are SSM, LPSW, SVC {and perhaps others if the need arises}.
As the kernel interprets privileged instructions it must produce and accept a virtual 64 bit PSW like that described in POP. Bits 2 thru 7 of the logical PSW {(d4)} correspond to bits 34 thru 39 of the virtual BC mode PSW and bits 24 thru 47 of the logical PSW correspond to bits 40 thru 63 of the virtual PSW. The right two bytes of the data key in C11 correspond to the left two bytes of the virtual PSW. Other information in the logical PSW plays no role in KVMA and is neither modified nor sensed in this simulation.
When an effect of a privileged instruction would be to turn on a bit in the system mask {(d11)} that was off and the corresponding bit of the "pending interrupt" {C10, (d10)} mask is on, the instruction is not simulated and the privileged instruction trap code is produced instead. See (ioint) also.
The kernel reads and writes the system mask as it interprets the above mentioned privileged commands but only the domain key holder changes the pending interrupt mask.
The calls on the domain key to fetch and put domain components use component addresses C0 thru C47. Domain keys, start keys and resume keys designate a domain by designating the (_domain root) of the domain. The domain root is one of the three nodes that comprise the domain.
C0 is the (_brand) of the domain. It does not influence the behavior of a process in the domain. This slot influences the DOMAIN_TOOL. See (p2,mkdomk).
C12 defines the priority of the domain. The kernel maintains this information. See (kernel-logic,scheduler) for how it is used.
Slot 13 will receive a DK(0) when it becomes available and may receive DK(0) subsequent to becoming available until it is entered again with a start key or the node is severed. The kernel will not place anything besides DK(0) or DK(1) in C13. If something else is placed in this slot the domain may not run. C13 will receive DK(1) any time a process runs in the domain. The above can be summarized by saying that C13 is not the only place in the system where the kernel remembers whether there is a process in the domain root. If C13 is stored into, the action may or may not be noticed by the system. See (p1,dsterm). Also see (kernel-logic,hook) for motivation of C13.
Slot 14 of the domain root should hold a node key to the (_general key node). The slots of the general key node are addressed as C16 thru C31. Slot 15 of the domain root should hold a node key to the (_regs node). The slots of the regs node are addressed C32 thru C47. The general keys and regs nodes are called (_domain annexes).
We say that each of these domains is a different object but these objects are of the same type.
The kernel's stalling mechanism {(entrystall)} provides efficient management of the queue of those processes waiting for the resource.
Domains are very similar to monitors. See (p3,bhmonitor).
Design Proposal for Supporting CMS
CMS executes SVC's and LPSW's rather frequently. A modification to the kernel would greatly speed up the interpretation of these instructions. These instructions are intended to change the PSW key. The main benefit of this is to make CMS file directories much safer.
Suppose that another bit in the domain's PSW indicated that the SVC-LPSW support were in effect. The following new features of domain architecture would appear.
C3 would be a node key to a node of 16 memory keys -- one for each possible PSW key. Three new fields would be defined in the domain root: Virtual-PSW-Key {4 bits}, Virtual-System-Mask {8 bits}, Virtual-Interrupts-Pending {8 bits}.
LPSW's and SVC's with codes less than 0FD both introduce new PSW's. In such cases PSW keys and system masks from the specified PSW would replace their virtual counterparts. If the new virtual-system-mask intersected the virtual-interrupts-pending, a message would be sent to the domain keeper. The new virtual-PSW-key would cause the corresponding memory key from the new domain annex to be used as the memory of the domain.
An SVC would generate an Old-PSW from the real PSW and the current virtual PSW keys and system masks.
The space conservation idea is to use 11 byte data keys in the domain root to keep the 36 bytes of the "control information" in four keys instead of six.
Perhaps the main problem is in documentation. Most current documentation is written at the abstraction level of the holder of a node key to a domain root. The documentation can be changed to the abstraction level of the domain key holder with out changing the semantics of any key. Then byte reshuffeling can be done in the domain root and leave all programs outside the kernel intact.
The net effect is to free slots 8 and 9 of the domain root. Domain key orders 8, 9, 32+8 and 32+9 would become valid.