Exceptions in DLX

As in unpipelined implementations, the most difficult exceptions have two properties:

They occur within instructions;
The instruction (within which the exception occurred) must be restartable.

If the pipeline can be stopped so that the instructions just before the faulting instruction are completed and those after it can be restarted from scratch, the pipeline is said to have precise exceptions. Supporting precise exceptions is a requirement in many systems. In practice, the need for accommodating virtual memory have led designers to always provide precise exceptions for the integer pipeline.
 

Exceptions that may occur in the DLX pipeline

Pipeline stage	Problem exceptions occurring
IF	Page fault on instruction fetch; misaligned memory access; memory-protection violation
ID	Undefined or illegal opcode
EX	Arithmetic exception
MEM	Page fault on data fetch; misaligned memory access; memory-protection violation
WB	None

 

1)With pipelining, multiple exceptions may occur in the same clock cycle because there are multiple instructions in execution.

Example

LW	IF	ID	EX	MEM	WB
ADD		IF	ID	EX	MEM	WB

This pair of instructions can cause a data page fault and an arithmetic exception at the same time, since LW is in the MEM stage while the ADD is in the EX stage.

This can be handled by dealing with only the data page fault and then restarting the execution. The second exception will reoccur and will be handled independently.

2) Exceptions may even occur out of order; that is an instruction may cause an exception before an earlier instruction causes one.

Example

LW	IF	ID	EX	MEM	WB
ADD		IF	ID	EX	MEM	WB

This time consider the case when LW gets a data page fault, seen when the instruction is in MEM, and ADD gets an instruction page fault, seen when the ADD instruction is in IF. The instruction page fault will actually occur first even though it is caused by a later instruction.

Since we are implementing precise exceptions, the pipeline is reqiured to handle the exception caused by the LW instruction first! So, the pipeline cannot simply handle an exception when it occurs in time, since that will lead to exceptions occurring out of unpipelined order.

Instead, it is done through the following steps:

- the hardware posts all exceptions caused by a given instruction in a status vector associated with that instruction;

- the status vector is carried along as the instruction goes down the pipeline;

- once the exception indicator is set in the exception status vector, any control signals that may cause a data value to be written is turned off (this includes both register and memory writes);

-  when an instruction enters WB, the exception status vector is checked;

- if any exceptions are posted, they are handled in the order in which they would occur in time on an unpipelined machine.