A couple of examples may be helpful. Suppose we have a program that attempts to divide a number by zero, an obvious error condition. This error will be reported as an exception when it is detected during the execution of the divide instruction. It is synchronous because the same error will occur at the same place in the program whenever the program is run (assuming the data values are always the same). Let’s further suppose an I/O operation, such as reading a record from a disk, is executing while we are running our program. At some point, the I/O operation completes and this fact is reported. The mechanism used to report the I/O completion is an event, because it is caused by an action outside of the currently executing instruction. The event is asynchronous, meaning it is not tied to the execution of the running program and it can occur at any time.

Just as there are two types of exceptions at the MI, errors and user-defined conditions, there are two types of events. The two types of MI events are object-related events, such as a message limit being reached on a queue, and machine-related events, such as a specific time interval elapsing. An MI process can monitor the occurrence of a set of events and take action based on some or all of the events.

With the introduction of the ILE program and process models, some changes were made to the exception model. An exception at the MI is a formally architected process message. All process messages are retained in the process queue space, which is a part of the ILE process structure described in a previous section. Because the exception is reported as a message, a delay is possible between the signaling and the processing of the exception. So far, the characteristics of exception structure just described are the same for the original models and for the ILE models.

New for ILE is that the exception monitoring and handling now are explicitly controlled by the MI user. Exception monitors are used to detect the occurrence of particular exceptions. Instructions placed in the MI instruction stream enable and disable these exception monitors. Multiple monitors can be enabled at the same time. Each monitor has a priority, so exception searching and handling is based on priority when more than one monitor is enabled. Associated with each monitor is an exception handler routine. An exception handler is always an external ILE procedure.

SLIC supports both event and exception monitoring and handling. In Chapter 5, we saw that access to system objects was monitored by the machine. This capability, plus some special system-linkage instructions inserted into the PowerPC instruction stream, can accomplish most of the event-monitoring function. Much of the exception-monitoring function is accomplished by the hardware and is reported to the SLIC exception-handling routines through the PowerPC interrupt mechanism. In the next section, we look at the exception management component of SLIC.

SLIC Exception Management

Exception management in SLIC is primarily a routing function. The PowerPC interrupt mechanism starts the routing function whenever the hardware detects an interrupt. Once an exception occurs, all applicable SLIC exception handlers are given a chance to handle the exception. If the exception is handled, the process continues as if nothing happened. If the exception is not handled in the SLIC, the process is terminated and the exception is passed to the appropriate ILE exception handler.

Interrupts are classified by whether they are caused specifically by the execution of an instruction or by some other system event. The PowerPC architecture defines a total of 15 types of interrupts. Five of these interrupts are system-caused. They are

•  System Reset — This interrupt occurs whenever the system is reset or powered on.

•  Machine Check — A machine check interrupt reports hardware malfunctions.

•  External — An external interrupt notifies the processor that some event outside the processor (e.g., I/O) needs attention.

•  Performance Monitor — If the performance monitoring capability is enabled, this interrupt notifies the processor that some event being monitored has occurred.

•  Decrementer — The decrementer is used for timing functions. This interrupt notifies the processor that some time interval has expired.

The instruction-caused interrupts are

•  Data Storage — This interrupt indicates that an instruction has attempted a data-storage access that cannot be performed. This type of interrupt is used to report an effective address that cannot be translated (a page fault), a storage protection violation, or an effective address overflow (EAO) exception.

•  Instruction Storage — This interrupt is similar to the data-storage interrupt, except it is caused by an attempt to fetch the next instruction to be executed.

•  Direct-Store Error — This interrupt is also similar to the data-storage interrupt, except it occurs when the access is made to a direct-store (DS) address. Note you cannot get a page fault on a DS address.

•  Alignment — The alignment interrupt occurs when there is an attempt to access an operand that is supposed to be aligned on a memory boundary but isn’t.

•  Program — The program interrupt is used to report such things as the processor’s attempt to execute a privileged instruction without authority to do so, or its attempt to execute an invalid opcode.

•  Floating-Point Unavailable — This interrupt occurs when an attempt is made to execute a floating-point instruction and a bit in the MSR indicates that the processor cannot execute any floating-point instructions. The PowerPC architecture allows floating-point operations to be inhibited.

•  Floating-Point Assist — This interrupt is used to allow software assistance for relatively infrequent and complex floating-point operations. The processor must recognize the floating-point instruction as one that is implemented in software, and generate this type of interrupt.

•  Trace — The capability to do a single-step trace on all instructions or to trace all branches is enabled by bits having been set in the MSR. When these bits are set, a trace interrupt is generated after the successful execution of every instruction being traced.

•  System Call — A System Call instruction, which we describe in the next section, can be placed in the instruction stream. The execution of this instruction causes a system call interrupt to be generated.

•  System Call Vectored — A System Call Vectored instruction, which we also describe in the next section, is similar to the System Call instruction, except that with the System Call Vectored instruction, control can be passed to any one of 128 routines.