Filter
Top Products
User’s Manual
Preliminary PPC440x5 CPU Core
intrupts.fm.
September 12, 2002
Page 199 of 589
6.6 Interrupt Ordering and Masking
It is possible for multiple exceptions to exist simultaneously, each of which could cause the generation of an
interrupt. Furthermore, the PowerPC Book-E architecture does not provide for the generation of more than
one interrupt of the same class (critical or non-critical) at a time. Therefore, the architecture defines that inter-
rupts are ordered with respect to each other, and provides a masking mechanism for certain persistent inter-
rupt types.
When an interrupt type is masked (disabled), and an event causes an exception that would normally generate
an interrupt of that type, the exception persists as a status bit in a register (which register depends upon the
exception type). However, no interrupt is generated. Later, if the interrupt type is enabled (unmasked), and
the exception status has not been cleared by software, the interrupt due to the original exception event will
then finally be generated.
All asynchronous interrupt types can be masked. Machine Check interrupts can be masked, as well. In addi-
tion, certain synchronous interrupt types can be masked. The two synchronous interrupt types which can be
masked are the Floating-Point Enabled exception type Program interrupt (masked by MSR[FE0,FE1), and
the IAC, DAC, DVC, RET, and ICMP exception type Debug interrupts (masked by MSR[DE]).
Architecture Note: When an otherwise synchronous, precise interrupt type is “delayed” in
this fashion via masking, and the interrupt type is later enabled, the
interrupt that is then generated due to the exception event that
occurred while the interrupt type was disabled is then considered a
synchronous, imprecise class of interrupt.
In order to prevent a subsequent interrupt from causing the state information (saved in SRR0/SRR1,
CSRR0/CSRR1, or MCSRR0/MCSRR1) from a previous interrupt to be overwritten and lost, the PPC440x5
core performs certain functions. As a first step, upon any non-critical class interrupt, the processor automati-
cally disables any further asynchronous, non-critical class interrupts (External Input, Decrementer, and Fixed
Interval Timer) by clearing MSR[EE]. Likewise, upon any critical class interrupt, hardware automatically
disables any further asynchronous interrupts of either class (critical and non-critical) by clearing MSR[CE]
and MSR[DE], in addition to MSR[EE]. The additional interrupt types that are disabled by the clearing of
MSR[CE,DE] are the Critical Input, Watchdog Timer, and Debug interrupts. For machine check interrupts, the
processor automatically disables all maskable interrupts by clearing MSR[ME] as well as MSR[EE,CE,DE].
This first step of clearing MSR[EE] (and MSR[CE,DE] for critical class interrupts, and MSR[ME] for machine
checks) prevents any subsequent asynchronous interrupts from overwriting the relevant save/restore regis-
ters (SRR0/SRR1, CSRR0/CSRR1, or MCSRR0/MCSRR1), prior to software being able to save their
contents. The processor also automatically clears, on any interrupt, MSR[WE,PR,FP,FE0,FE1,IS,DS]. The
clearing of these bits assists in the avoidance of subsequent interrupts of certain other types. However, guar-
anteeing that these interrupt types do not occur and thus do not overwrite the save/restore registers also
requires the cooperation of system software. Specifically, system software must avoid the execution of
instructions that could cause (or enable) a subsequent interrupt, if the contents of the save/restore registers
have not yet been saved.
6.6.1 Interrupt Ordering Software Requirements
The following list identifies the actions that system software must avoid, prior to having saved the
save/restore registers’ contents:
• Reenabling of MSR[EE] (or MSR[CE,DE] in critical class interrupt handlers)