Trap sequence

The hardware will perform a set sequence of operations, regardless of whether the trap is a synchronous fault or an asynchronous interrupt. Interrupt requests , page faults, illegal instructions, or system calls will all be handled the same way. The trap recognition sequence transfers control to the kernel and enters kernel or supervisor mode, with information saved about where the trap occurred and what kind of trap it was.

• Further traps are disabled by clearing the Trap Enable bit in the PSR (Processor Status Register). This prevents further traps or interrupts from being recognized while in the middle of processing this one, which will avoid having a second trap overwrite data the system needs to keep in order to return from the current trap.

• The pS bit, previous S bit in the PSR , is set to the current S bit value to preserve information about where this trap came from. If the S bit was set, the CPU was already in supervisor mode or in the kernel. If the S bit was clear, the trap occurred while user code was executing. This is referenced by the kernel trap-handling code to determine what the proper response should be to certain traps.

• The S bit is set. This indicates that you are now in supervisor mode.

• The CWP (Current Window Pointer) is decremented to move to the next register window: this move does not cause a window overflow trap even if the move is into an invalid register window. It is the responsibility of the software to identify this case and handle it. This particular feature does put some interesting restrictions on the code that actually handles the traps.

• PC and nPC contents are stuffed into %l1 and %l2 of the new trap window (since the local registers are the only ones guaranteed to be available at this point).

• The tt (Trap Type) field of the TBR (Trap Base Register) is set, based on what kind of fault or request occurred. This identifies the address of the trap-handling code for the specific trap.

• The PC and nPC are set to the value of the TBR (and TBR + 4 ). This forces a branch to these locations, which have been set up to contain a short piece of code to get to the correct routine to handle the particular type of trap received.

Thus the trap sequence as performed by the hardware looks like:

• Recognize the trap.

• Get to a new window (an implicit save instruction).

• Set TBR according to the trap type.

• Force a branch to the trap instructions ” the address in the TBR .

Turning off the Enable Traps bit is necessary, but since doing so also delays interrupt recognition, this has to be done for as short a time as possible. The code must also be carefully written; if a trap is requested (a page fault, for example) while traps are "disabled," a watchdog reset will occur.

The current window pointer (CWP, in the Processor Status Register) indicates the registers that are in use. Since registers behave like a circular buffer, this acts as a circular list pointer, so it will cycle around through the complete register set. Sooner or later, it will overlap, when the "new register window" it indicates is not actually free for use. This case is the source of a window overflow trap (or a window underflow, when moving in the other direction), and because a trap at this point would cause a watchdog reset, the CWP may in fact be changed to point to an invalid window. For this reason, the hardware and software in the trap-handling process can only use the local ( %l0 “ %l7 ) registers. No other registers can be touched. This will produce a nonstandard stack frame on the stack: one in which, for example, the return address (in %i7 ) is not really a valid pointer.

The Trap Base Register is normally set up once during the initialization of the system to point to some page boundary. It looks like this:

Figure 26-1. Trap Base Register

You will notice that the lower bits are always zeroes, and the next eight bits are the trap type field ” filled automatically, based on the type of the trap as determined by the hardware. This means that if the base address register was initialized by the kernel to start at location 0x4000, then a trap type 1 (which is a text fault or an instruction access problem) would cause the type field to be set to 1, the lower bits are zeroes, and we are thus branching immediately to location 0x4010. For an illegal instruction (trap type 2), the hardware sends us to 0x4020. There's not a lot of space between these two addresses (four words, in fact), so the "trap code" generally consists of an immediate branch off to someplace else ” where we've got enough room to do some real work! You now can see why the trap-handling code is written in assembly language.