Layout of an EROS Domain

An EROS domain is made up of three nodes: the domain root, the general registers node, and the key registers node. There are three kinds of constraints on the content layout of these nodes:

• Requirements for the domain to be well-formed.
• Universal slot usage conventions, which apply to all architectures.
• Slot usage conventions that apply to all 32-bit architectures.
• Slot usage constraints that are specific to a particular implementation.

1. Well-Formed Domains

In order to be well-formed, a domain must meet the following constraints:

1. The domain root node must have a read-write node key in slot 14. The node in this slot will act as the general registers node.

2. The domain root node must have a read-write node key in slot 15. The node in this slot will act as the key registers node.

   Note 1: we are contemplating a design change in which a zero number key would be permissable in slot 15 to reduce the overhead of rehosted programs, which neither send nor receive messages. In the event that a zero number key was present and the domain was not marked as "foreign," the domain keeper would be invoked if a reference was made to the domain's key registers.

3. The domain root node, general registers node, and key registers node (if present) must be distinct.

4. All keys in register slots must be number keys. Register slots include all slots in the general registers node, and those slots in the domain root designated as holding register values, whether or not those slots are used by a particular architecture.

5. All keys in reserved slots must be zero number keys.

A domain is checked to verify that it is well-formed whenever an operation is performed on a start key, resume key, or domain key. If the domain is discovered to be malformed, it is placed in a faulted state, and will not execute instructions until corrective action is taken. If a valid keeper key is present, the keeper will be invoked to inform it of the fault.

1.1 Non-Requirements:

In spite of what you might reasonably expect, the following are not required in order for a domain to be well-formed:

• A valid address space key. A domain without a valid address space key simply does not fetch instructions.
• A valid schedule key. A domain without a valid schedule key simply does not fetch instructions.
• A valid keeper key. The absence of a keeper key is only an issue when the domain takes a fault. If no keeper can be notified, the domain simply becomes unable to execute instructions.

2. Universal Slot Usage Conventions

All implementations impose the following usage constraints on the slots in a domain root. Slots shown as "reserved" must hold a zero number key until these features are implemented.

2.1. Send and Receive Information

The message send and receive information share a common structure for nibbles 0 through 15. These nibbles are used as follows:

Note that the send and receive information blocks correspond to specific registers in the implementation architecture. Two common message cases are messages that pass no keys and messages that pass no string. The layout of the send and receive information blocks is designed to map neatly onto a 32-bit register set to minimize the number of registers clobbered by the message mechanism in these cases.

2.2. Invocation Control Block

Only the bottom three bytes of the invocation control block register have defined values. The remaining bytes must be zero. The invocation control block controls both the invocation and the send and receive of message strings, and is layed out as follows:

3. Common 32-bit Architecture Constraints

Slot 9 of the domain root is reserved in all 32-bit architectures to contain the values of the PC and SP registers. This is to simplify the construction of domain generation tools by keeping registers that support concepts common to all 32-bit machines in common slots. This, on 32-bit architectures, the layout of this slot is as follows:

4. i386/i486/Pentium Domain Layout

The following tables give the register layouts used on the i386 family of processors. Layout inherited from above is included in normal face, and machine-specific additions are is shown in boldface.

As it happens, all of the integer machine registers fit in the domain root on the x86 family. Registers associated with auxiliary components, such as the floating point unit and the hardware debugging registers are kept in the general registers node. Whether to reload the floating point registers can be determined by examining the bits in the EFLAGS register.

Given all of that, the layout of the general registers shown below may make more sense.