IBM powerpc 750gx Manuel D’Utilisation
User’s Manual
IBM PowerPC 750GX and 750GL RISC Microprocessor
PowerPC 750GX Overview
Page 48 of 377
gx_01.fm.(1.2)
March 27,2006
1.7 Exception Model
The following sections describe the PowerPC exception model and the 750GX implementation. A detailed
description of the 750GX exception model is provided in Chapter 4, Exceptions, on page 151 in this manual.
description of the 750GX exception model is provided in Chapter 4, Exceptions, on page 151 in this manual.
1.7.1 PowerPC Exception Model
The PowerPC exception model allows the processor to interrupt the instruction flow to handle certain situa-
tions caused by external signals, errors, or unusual conditions arising from the instruction execution. 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. System software must
complete the saving of the processor state prior to servicing the exception. Exception processing proceeds in
supervisor mode.
tions caused by external signals, errors, or unusual conditions arising from the instruction execution. 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. System software must
complete the saving of the processor state prior to servicing the exception. Exception processing proceeds in
supervisor mode.
Although multiple exception conditions can map to a single exception vector, a more specific condition can be
determined by examining a register associated with the exception. For example, the MSR, DSISR, and
FPSCR contain status bits that further identify the exception condition. Additionally, some exception condi-
tions can be explicitly enabled or disabled by software.
determined by examining a register associated with the exception. For example, the MSR, DSISR, and
FPSCR contain status bits that further identify the exception condition. Additionally, some exception condi-
tions can be explicitly enabled or disabled by software.
The PowerPC Architecture requires that exceptions be handled in specific priority and program order. There-
fore, although a particular implementation might recognize exception conditions out of order, they are
handled in program order. When an instruction-caused exception is recognized, any unexecuted instructions
that appear earlier in the instruction stream, including any that are not dispatched, must complete before the
exception is taken. Any exceptions those instructions cause must also be handled first. Likewise, asynchro-
nous, precise exceptions are recognized when they occur. However, they are not handled until the instruc-
tions currently in the completion queue successfully retire or generate an exception, and the completion
queue is emptied.
fore, although a particular implementation might recognize exception conditions out of order, they are
handled in program order. When an instruction-caused exception is recognized, any unexecuted instructions
that appear earlier in the instruction stream, including any that are not dispatched, must complete before the
exception is taken. Any exceptions those instructions cause must also be handled first. Likewise, asynchro-
nous, precise exceptions are recognized when they occur. However, they are not handled until the instruc-
tions currently in the completion queue successfully retire or generate an exception, and the completion
queue is emptied.
Unless a catastrophic condition causes a system reset or machine-check exception, only one exception is
handled at a time. For example, if one instruction encounters multiple exception conditions, those conditions
are handled sequentially in priority order. After the exception handler completes, the instruction processing
continues until the next exception condition is encountered. Recognizing and handling exception conditions
sequentially guarantees system integrity.
handled at a time. For example, if one instruction encounters multiple exception conditions, those conditions
are handled sequentially in priority order. After the exception handler completes, the instruction processing
continues until the next exception condition is encountered. Recognizing and handling exception conditions
sequentially guarantees system integrity.
When an exception is taken, information about the processor state before the exception was taken is saved in
SRR0 and SRR1. Exception handlers must save the information stored in SRR0 and SRR1 early to prevent
the program state from being lost due to a system reset and machine-check exception or due to an instruc-
tion-caused exception in the exception handler, and before re-enabling external interrupts. The exception
handler must also save and restore any GPR registers used by the handler.
SRR0 and SRR1. Exception handlers must save the information stored in SRR0 and SRR1 early to prevent
the program state from being lost due to a system reset and machine-check exception or due to an instruc-
tion-caused exception in the exception handler, and before re-enabling external interrupts. The exception
handler must also save and restore any GPR registers used by the handler.