Filter
Top Products
User’s Manual
IBM PowerPC 750GX and GL RISC Microprocessor
gx_04.fm.(1.2)
March 27, 2006
Exceptions
Page 151 of 377
4. Exceptions
The operating environment architecture (OEA) portion of the PowerPC Architecture defines the mechanism
by which PowerPC processors implement exceptions (referred to as interrupts in the architecture specifica-
tion). Exception conditions can be defined at other levels of the architecture. For example, the user instruction
set architecture (UISA) defines conditions that can cause floating-point exceptions; the OEA defines the
mechanism by which the exception is taken.
The PowerPC exception mechanism allows the processor to change to supervisor state as a result of unusual
conditions arising in the execution of instructions and from external signals, bus errors, or various internal
conditions. When exceptions occur, information about the state of the processor is saved to certain registers,
and the processor begins execution at an address (exception vector) predetermined for each exception.
Processing of exceptions begins in supervisor mode.
Although multiple exception conditions can map to a single exception vector, often a more specific condition
can be determined by examining a register associated with the exception—for example, the Data Storage
Interrupt Status Register (DSISR) and the Floating-Point Status and Control Register (FPSCR). The high-
order bits of the Machine State Register (MSR) are also set for some exceptions. Software can explicitly
enable or disable some exception conditions.
The PowerPC Architecture requires that exceptions be taken in program order. Therefore, although a partic-
ular implementation might recognize exception conditions out of order, they are handled strictly in order with
respect to the instruction stream. When an instruction-caused exception is recognized, any unexecuted
instructions that appear earlier in the instruction stream, including any that have not yet entered the execute
state, are required to complete before the exception is taken. For example, if a single instruction encounters
multiple exception conditions, those exceptions are taken and handled based on the priority of the exception.
Likewise, exceptions that are asynchronous and precise are recognized when they occur, but are not handled
until all instructions currently in the execute stage successfully complete execution and report their results.
To prevent loss of state information, exception handlers must save the information stored in the Machine
Status Save/Restore Registers, SRR0 and SRR1, soon after the exception is taken to prevent this informa-
tion from being lost due to another exception being taken. Because exceptions can occur while an exception
handler routine is executing, multiple exceptions can become nested. It is up to the exception handler to save
the necessary state information if control is to return to the excepting program.
In many cases, after the exception handler returns, there is an attempt to execute the instruction that caused
the exception (for example, a page fault). Instruction execution continues until the next exception condition is
encountered. Recognizing and handling exception conditions sequentially guarantees that the machine state
is recoverable and processing can resume without losing instruction results.
In this book, the following terms are used to describe the stages of exception processing.
Recognition Exception recognition occurs when the condition that can cause an exception is identified by
the processor.
Taken An exception is said to be taken when control of instruction execution is passed to the excep-
tion handler. That is, the context is saved, the instruction at the appropriate vector offset is
fetched, and the exception handler routine is begun in supervisor mode.
Handling Exception handling is performed by the software linked to the appropriate vector offset.
Exception handling is begun in supervisor mode (referred to as privileged state in the archi-
tecture specification).