beautypg.com

5 exception model, 1 powerpc exception model, Powerpc exception model -22 – Motorola MPC8260 User Manual

Page 110: Bus configuration register (bcr) -25

background image

2-22

MPC8260 PowerQUICC II UserÕs Manual

MOTOROLA

Part I. Overview

ways 0, 1, and 2 but it is not possible to lock just way0 and way2). When using way locking
at least one way must be left unlocked. The maximum number of lockable ways is three.

Unlike entire cache locking, invalid entries in a locked way are accessible and available for
data placement. As hits to the cache Þll invalid entries within a locked way, the entries
become valid and locked. This behavior differs from entire cache locking where nothing is
placed in the cache, even if invalid entries exist in the cache. Unlocked ways of the cache
behave normally.

2.5 Exception Model

This section describes the PowerPC exception model and implementation-speciÞc details
of the MPC8260 core.

2.5.1 PowerPC Exception Model

The PowerPC exception mechanism allows the processor to change to supervisor state as a
result of external signals, errors, or unusual conditions arising in the execution of
instructions. 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 occurs in supervisor mode.

Although multiple exception conditions can map to a single exception vector, a more
speciÞc condition may be determined by examining a register associated with the
exceptionÑfor example, the DSISR identiÞes instructions that cause a DSI exception.
Additionally, some exception conditions can be explicitly enabled or disabled by software.

The PowerPC architecture requires that exceptions be handled in program order; therefore,
although a particular implementation may recognize exception conditions out of order,
exceptions are taken in strict order. 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 stage, are required to complete before the exception is
taken. Any exceptions caused by those instructions are handled Þrst. Likewise, exceptions
that are asynchronous and precise are recognized when they occur, but are not handled until
the instruction currently in the completion stage successfully completes execution or
generates an exception, and the completed store queue is emptied.

Unless a catastrophic condition causes a system reset or machine check exception, only one
exception is handled at a time. If, for example, a single instruction encounters multiple
exception conditions, those conditions are handled sequentially. After the exception handler
handles an exception, the instruction execution continues until the next exception condition
is encountered. However, in many cases there is no attempt to re-execute the instruction.
This method of recognizing and handling exception conditions sequentially guarantees that
exceptions are recoverable.

Exception handlers should save the information stored in SRR0 and SRR1 early to prevent
the program state from being lost due to a system reset or machine check exception or to