1
\$\begingroup\$

I have been refreshing my memory on pipelined processors for fun. Currently, I'm reviewing interrupt implementations in (in-order) pipelined CPUs, and various complications that arise. I've found this PDF to be helpful, but it leaves some questions as exercises to the reader.

One of these questions is:

What makes precise interrupts hard? Delayed branches cause a problem. What is it?

My educated guess is that "if an exception or I/O interrupt happens in a delay slot, state about the processor having a branch pending- exclusive to delay slots- is not accounted for when restarting the instruction.

My solution would be to create some state that indicates we are within a delay slot, along with information about the result of the branch. This should work because if the delay slot faults, the branch will complete so that sequential execution of instructions matches pipelined execution.

However, I'm not confident in my solution is correct. Is there some other state or explanation I may be missing?

\$\endgroup\$
1
\$\begingroup\$

The interrupt hits after the branch (i.e. with the Instruction Pointer at the new location) but before the delay slot instruction has executed.

How do you know where you branched from?

That's where you need to re-fetch the delay slot instruction from.

See : COMEFROM instruction.

\$\endgroup\$
  • \$\begingroup\$ Can you elaborate on "How do you know where you branched from?". My understanding of that phrase: If the new IP/address to fetch is pointing to the branch destination, but the exception arrives before the delay slot finishes, we don't know whether to execute the delay slot or IP-4 when we return from interrupt, since IP already points to the destination. \$\endgroup\$ – cr1901 Jan 20 '17 at 4:35
  • \$\begingroup\$ Worse than that, we don't know what instruction was IN the delay slot! Or where to re-fetch it from, since we could have branched from anywhere. So you need to store a copy of the delay slot instruction as part of the interrupt state, increasing its size and potentially slowing down. \$\endgroup\$ – Brian Drummond Jan 20 '17 at 10:02
  • \$\begingroup\$ Accepting answer, just one follow up question (prev comment should be deleted- editing fail): Do we store only a copy of the delay slot instruction (presumably by forcefully putting it into the ID stage?) instead of saving the delay slot IP and branch dest IP? If so (i.e. we only store the delay slot instruction), what happens if the delay slot triggers an exception again? \$\endgroup\$ – cr1901 Jan 22 '17 at 9:01
  • \$\begingroup\$ You CANNOT store the delay slot instruction in the ID stage ... running the exception handler will overwrite that! Now, your supplementary question, what happens if the delay slot triggers another exception? That's a good question : one of the questions you SHOULD be asking if you're contemplating such a design. \$\endgroup\$ – Brian Drummond Jan 22 '17 at 12:27
  • \$\begingroup\$ For those wondering, one way to prevent a delay slot from triggering another exception, which would lose previously-saved branching information, is to always re-execute the branch instruction, and keep a status bit about whether we triggered an exception in a delay slot. This is described on page 3-7 of this MIPS R3000 manual. \$\endgroup\$ – cr1901 Feb 21 '17 at 10:44

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.