Types of Exception

590
Chapter 8
Exceptional Control Flow
Class Interrupt Trap Fault Abort
Cause Signal from I/O device Intentional exception Potentially recoverable error Nonrecoverable error
Async/Sync Async Sync Sync Sync
Return behavior Always returns to next instruction Always returns to next instruction Might return to current instruction Never returns
Figure 8.4 Classes of exceptions. Asynchronous exceptions occur as a result of events in I/O devices that are external to the processor. Synchronous exceptions occur as a direct result of executing an instruction.
returns to the interrupted program by executing a special "return from interrupt" instruction, which pops the appropriate state back into the processor's control and data registers, restores the state to user mode (Section 8.2.3) if the exeption interrupted a user program, and then returns control to the interrupted program.
8.1.2 Classes of Exceptions

Exceptions can be divided into four classes: interrupts, traps, faults, and aborts. The table in Figure 8.4 summarizes the attributes of these classes.
Interrupts
Interrupts occur asynchronously as a result of signals from I/O devices that are external to the processor. Hardware interrupts are asynchronous in the sense that they are not caused by the execution of any particular instruction. Exception handlers for hardware interrupts are often called interrupt handlers. Figure 8.5 summarizes the processing for an interrupt. I/O devices such as network adapters, disk controllers, and timer chips trigger interrupts by signalling a pin on the processor chip and placing the exception number on the system bus that identifies the device that caused the interrupt. After the current instruction finishes executing, the processor notices that the interrupt pin has gone high, reads the exception number from the system bus, and then calls the appropriate interrupt handler. When the handler returns, it returns control to the next instruction (i.e., the instruction that would have followed the
(2) Control passes to handler after current instruction finishes
(1) Interrupt pin goes high during execution of current instruction
Icurr ~ Inext
(3) Interrupt handler runs (4) Handler returns to next instruction
Figure 8.5 Interrupt handling. The interrupt handler returns control to the next instruction in the application program's control flow.
Section 8.1
Exceptions
591
(1) Application makes a syscall Inext system call
(2) Control passes to handler (3) Trap handler runs (4) Handler returns to instruction following the syscall
Figure 8.6 Trap handling. The trap handler returns control to the next instruction in the application program's control flow.
current instruction in the control flow had the interrupt not occurred). The effect is that the program continues executing as though the interrupt had never happened. The remaining classes of exceptions (traps, faults, and aborts) occur synchronously as a result of executing the current instruction. We refer to this instruction as the faulting instruction.
Traps
Traps are intentional exceptions that occur as a result of executing an instruction. Like interrupt handlers, trap handlers return control to the next instruction. The most important use of traps is to provide a procedure-like interface between user programs and the kernel known as a system call. User programs often need to request services from the kernel such as reading a file (read), creating a new process (fork), loading a new program (execve), or terminating the current process (exi t). To allow controlled access to such kernel services, processors provide a special "syscall n" instruction that user programs can execute when they want to request service n. Executing the syscall instruction causes a trap to an exception handler that decodes the argument and calls the appropriate kernel routine. Figure 8.6 summarizes the processing for a system call. From a programmer's perspective, a system call is identical to a regular function call. However, their implementations are quite different. Regular functions run in user mode, which restricts the types of instructions they can execute, and they access the same stack as the calling function. A system call runs in kernel mode, which allows it to execute instructions, and accesses a stack defined in the kelnel. Section 8.2.3 discusses user and kernel modes in more detail.
Faults
Faults result from error conditions that a handler might be able to correct. When a fault occurs, the processor transfers control to the fault handler. If the handler is able to correct the error condition, it returns control to the faulting instruction, thereby reexecuting it. Otherwise, the handler returns to an abort routine in the kernel that terminates the application program that caused the fault. Figure 8.7 summarizes the processing for a fault.
592
Chapter 8
Exceptional Control Flow
(1) Current instruction causes a fault
(2) Control passes to handler (3) Fault handler runs
........................................ abort
(4) Handler either reexecutes current instruction or aborts
Figure 8.7 Fault handling. Depending on the whether the fault can be repaired or not, the fault handler either reexecutes the faulting instruction or aborts.
A classic example of a fault is the page fault exception, which occurs when an instruction references a virtual address whose corresponding physical page is not resident in memory and therefore must be retrieved from disk. As we will see in Chapter 10, a page is a contiguous block (typically 4 KB) of virtual memory. The page fault handler loads the appropriate page from disk and then returns control to the instruction that caused the fault. When the instruction executes again, the appropriate physical page is resident in memory and the instruction is able to run to completion without faulting.
Aborts
Aborts result from unrecoverable fatal errors-typically hardware errors such as parity errors that occur when DRAM or SRAM bits are corrupted. Abort handlers never return control to the application program. As shown in Figure 8.8, the handler returns control to an abort routine that terminates the application program.
8.1.3
Exceptions in Intel Processors
To help make things more concrete, let's look at some of the exceptions defined for Intel systems. A Pentium system can have up to 256 different exception types. Numbers in the range from a to 31 correspond to exceptions that are defined by the Pentium architecture, and thus are identical for any Pentium-class system. Numbers in the range from 32 to 255 correspond to interrupts and traps that are defined by the operating system. Figure 8.9 shows a few examples.
(1) Fatal hardware error occurs
Icurr
~-
(2) Control passes to handler
---,
....................................... ~ abort
(3) Abort handler runs
(4) Handler returns to abort routine
Figure 8.8 Abort handling. The abort handler passes control to a kernel abort routine that terminates the application program.

Types of Exception

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Types of Exception

Uploaded by

Copyright:

Available Formats

590

Exceptional Control Flow

Class Interrupt Trap Fault Abort

Async/Sync Async Sync Sync Sync

8.1.2 Classes of Exceptions

(1) Interrupt pin goes high during execution of current instruction

(3) Interrupt handler runs (4) Handler returns to next instruction

(1) Application makes a syscall Inext system call

Exceptional Control Flow

(1) Current instruction causes a fault

(2) Control passes to handler (3) Fault handler runs

(4) Handler either reexecutes current instruction or aborts

Exceptions in Intel Processors

(1) Fatal hardware error occurs

(2) Control passes to handler

(3) Abort handler runs

(4) Handler returns to abort routine

You might also like