3
$\begingroup$

Say you execute a clear interrupt instruction (CLI) in a pipelined CPU. While that instruction is being fetched, an interrupt occurs, so the instruction after the CLI is from the interrupt handler.
You excepted no interrupts because of the CLI instruction but you still got one. How is this problem solved?

$\endgroup$
4
$\begingroup$

Such a control hazard can be handled effectively the same way that a branch misprediction is handled. Either the CLI instruction commits and the interrupt handler fetch is treated as the mispredicted path and fetch is restarted after the CLI or the CLI instruction is not committed and the interrupt handler is treated as the correct path.

$\endgroup$
2
$\begingroup$

External interrupt are usually processed as traps (divide by zero, MMU faults...) in pipelined CPUs, to share resources and simplify the design. They are handled late in the pipeline, which can have some negative effects on interrupt latency.

For traps, the pipeline is flushed, all the partially executed instructions are discarded.

When implementing the CLI/STI instructions, one shall carefully ensure the correct synchronisation between the update of the flags and the detection of the interrupt.

While that instruction is being fetched, an interrupt occurs, so the instruction after the CLI is from the interrupt handler.

The interrupt request must be active before the CLI instruction is committed. If it is too late, the CPU will simply ignore it.

The interrupt request signal may need to be frozen when special instructions like CLI, STI, "read the machine-state-register-with-the-interrupt-bits" instructions traverse the pipeline.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.