TRAPS AND FAULTS

TRAPS AND FAULTS

DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY

DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY

DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY

Abnormal conditions which occur during instruction execution are often called traps, faults, or checks. Other events which disturb normal instruction flow are called interrupts. All of these events will be referred to as traps in this discussion. They are handled in a uniform manner. In addition, the KFC (Kernel Function Call) instruction shares some properties of traps. (See Chapter 4.4 below.) A trap causes control to be sent to a location which is 4,002,000B + 20B * Trap No., where the Trap No. is chosen according to the table below; KFC sends control to the location determined as though it were an XOP.

Trap Name Priority Trap No Explanation

All traps and KFC enter kernel mode, disable traps, and push the old state of the StackedStatusWord onto the EU stack. Instructions which result in traps have no other effect on the machine state; it is as though the instruction causing the trap were erased and replaced by the trap event.

Enabling or disabling traps affects only Reschedule, EU stack overflow, and IFU stack overflow; other traps are always enabled. The EU and IFU stack overflow traps occur when critical resources are on the verge of exhaustion, and both traps normally push the oldest frame in the registers out into storage to make more room; automatically disabling traps prevents these two traps from nesting, which would cause logical problems and require more reserved registers. Reschedule is also disabled because if a Reschedule were to occur during EU or IFU stack overflow, servicing it would require more reserved registers. All other traps with the exception of EU or IFU memory faults, can easily be avoided by the EU and IFU stack overflow trap handlers, so it is not necessary to disable them.

When traps are enabled, the IFU call stack has 11 entries for normal calls and converts the following call (which uses the 12th call stack entry) into an IFU stack overflow trap. When traps are disabled, all 15 call stack entries are available. Similarly, it is expected that SLimit will be set equal to L - 17, where L is the base of the earliest frame in the registers. Then any instruction will cause an EU stack overflow trap if, at the end of the instruction, traps are enabled and S is in the range [SLimit..SLimit+16). Then EU stack overflow trap will be requested with at least 17 unused registers in reserve for the trap handler, so 111 registers are available for use by normal frames.

There are no IFU stack underflow or EU stack underflow traps. During normal operation the earliest frame in the registers will contain a <pc, status> pair. Upon return to this <pc, status> pair an earlier frame from storage will be moved into the registers. This so-called "bogus frame" should have interrupts disabled.

Unlike IFU stack underflow, which is a normal event, EU stack underflow represents a programming error which the hardware doesn't detect. However, decrementing S too much can result in an EU stack overflow error if S is counted into the range [SLimit .. SLimit + 16).

A Reschedule interrupt is not synchronized with normal instruction execution, and it is appropriate to think of this trap as being inserted between instructions. It is impossible to have any other traps requesting concurrently. However, the Reschedule trap will push one more entries onto the IFU call stack and this push may result in IFU stack overflow. The priorities in the table above show that IFU stack overflow has higher priority than Reschedule, and Reschedule has higher priority than over EU stack overflow.

The EU Stack Overflow trap ordinarily occurs as the result of an instruction which advances S into the restricted region. The IFU stack overflow trap is the result of a call, and the Reschedule trap results from an external event. However, these events can also occur as a result of reenabling traps with S already inside the restricted region, with 12 or more IFU call stack entries. If traps are disabled and the Reschedule line is pulled high, the IFU status sets a private reschedule-pending bit to true. When traps are re-enabled, the Reschedule trap is taken.

It is illegal to reenable traps with 12 or more IFU call stack entries because, in this situation, it is not clear when the IFU stack overflow trap will occur. Because of this prohibition, any trap handler which reenables traps must do so before making any procedure calls. If this prohibition is obeyed, the IFU stack overflow trap handler will always have 3 call stack entries in reserve for its own activities and for EU page faults that result from its activities.

Traps may be reenabled with an EU stack overflow condition existing and/or reschedule-pending true. If this happens, the EU stack overflow trap will always occur immediately, and the Reschedule trap will occur immediately unless the EU stack overflow condition is true at the same time. This is a violation of the priorities given above, and it is appropriate to think of these events as happening between the instruction (SIP) which reenables interrupts and the following instruction. In all other situations, the EU stack overflow event occurs during the instruction and is of lower priority than anything else.

A practical situation in which traps are reenabled with S inside the restricted range is when the handler for a Lisp NaN trap decides to reenable traps in preparation for major work. It is possible that the NaN trap itself has made several pushes before the trap handler reenables traps. Hence, the EU stack overflow trap handler may be entered with only 17 - TBD words available. For this reason, it is necessary that the trap handler for any trap which is going to reenable interrupts obey a limit of TBD pushes to ensure that enough registers are available for the EU stack overflow handler.

The trap handler for a memory fault will save away the state of the current process and run the scheduler because it is impossible to continue execution of the current process in the event of such a fault.

The priority table above shows that memory faults have a lower priority than all other traps except Reschedule and EU stack overflow. However, an IFU page fault, for example, preempts the execution of the instruction; the only possible competitors for an IFU page fault are IFU stack overflow that result from the page fault trap itself; in this situation the relative priority is IFU stack overflow > IFU page fault.

Similarly, the only competitors of an EU memory fault are mode fault and EU stack overflow; and it is possible for the memory fault trap itself to cause IFU stack overflow. No other trap can request service simultaneously. The table above shows that IFU stack overflow > mode fault > EU page fault > EU write protect fault > EU stack overflow. (More specifically, in the event of a mode fault, the memory reference will never be initiated, so no disturbance of the cache occurs.)

A key issue with an EU memory fault trap is that it may nest with IFU stack overflow, if the next free frame for process state is not resident in storage. The deepest nested requirements of IFU stack overflow with an EU memory fault must not exceed the limit of 4 call stack entries and 17 - TBD local registers.

Except for the IFU and EU stack overflow and memory fault traps and the Reschedule trap, all traps in the table above are the predictable result of executing some instruction. All traps with priority equal to 4 are mutually exclusive, and the Mode fault trap is higher priority than any of these.

User mode can be turned on/off for the caller's context by using SIP[IFUYoungestL] to change the user mode bit; the subsequent RET or RETN to that context will then enter/leave user mode. Once in user mode, kernel mode can be reentered by executing a KFC instruction or by trapping. In user mode the following actions are illegal:

.

The Reschedule trap is used to interrupt dragon processors. The source for this trap can be either a dragon processor or an IO bridge acting on behalf of some IO device. A processor issues a reschedule request by executing IO writes to the InterruptStatus and InterruptMask registers. The processor may either direct its writes to a particular cache in which case the target cache's processor takes a trap, or broadcast them to all caches, in which case potentially all processors (including the one initiating the request) take a trap. When a cache receives the appropriate writes to its interrupt registers, it pulses the Reschedule line for its processor causing the reschedule bit to get set in the IFU. If trapsEnabled bit in the IFU is set then the processor takes a trap, otherwise it does so whenever trapsEnabled next gets set (see InterruptsDoc for further details). Once the IFU decides to take a trap, it clears trapsEnabled before executing the first instruction of the trap handler so as to avoid infinite regress. It is the task of the interrupt handler to actually clear the reschedule bit and reenable traps.

The instruction length for every instruction is determined from a computation on the high-order three bits of its opcode. Those opcodes not specifically defined as machine instructions are called Xops. Executing an Xop is semantically equivalent to a function call (DFC or LFC) to its trap location. Each instruction has its own trap location at 4,000,000B + 20B * opcode no. In addition, Xops of length two, three or five bytes push the literal following their opcodes, so that two-byte Xops push a one-byte literal value, three-byte Xops push a two-byte literal value, and five-byte Xops push a four-byte literal value.

Execution of an Xop does not change the status of the machine to Kernel mode.

It is expected that future revisions of the Dragon processor will deploy many Xops for new instructions.

There is a second category of undefined opcodes which must not be executed. These opcodes, six in all, are intentionally not described. The execution of these six opcodes has been forbidden in order to simplify the amount of logic required to implement the instructionset. Actually, these opcodes are defined and possibly even perform useful work, but they may be redefined in future versions of the machine. These six opcodes are indicated the instruction map by three asterisks, (***).

The KFC instruction is like an Xop in that it traps to a location which is 4,000,000B + 20B * opcode, and it advances the PC like an Xop, so that a procedure return will send control to the location after the KFC; however, KFC pushes the old IFU status and disables traps like a Trap.