felixlinker
felixlinker

Reputation: 80

How are pending exceptions managed by the RISC-V specification?

I'm working with the RISC-V specification and have a problem with pending interrupts/exceptions. I'm reading version 1.10 of volume II, published in May 7, 2017.

In section 3.1.14, describing the registers mip and mie it is said that:

Multiple simultaneous interrupts and traps at the same privilege level are handled in the following decreasing priority order: extern interrupts, software interrupts, timer interrupts, then finally any synchronous traps.

Up until that point I thought that exceptions, e.g. a misaligned instruction fetch exception on a JAL/JALR instruction, would be handled immediately by a trap because a) there is no way to continue executing your stream of instructions and b) there is no description of how an exception could be pending, i.e. there are no concepts described by the specification that could manage state for exceptions (for example registers like mip but for exceptions).

However, the paragraph cited above indicates something different. My questions are:

  1. Are there pending exceptions in RISC-V?
  2. If yes, how is it possible that the exception still can be handled after an interrupt was handled and isn't forgotten?

Upvotes: 2

Views: 853

Answers (1)

Baard
Baard

Reputation: 829

In my option there are pending exceptions in RISCV-V, exactly by the reason you stated. It is a matter of semantics, if two events occur simultaneously, and one is deferred, it must be pending. One must cater for the possibility of an asynchronous event (interrupt) occurring simultaneously with a trap, and (by section 3.1.14) the asynchronous event has priority. Depending on the implementation one does not neccesarely need to save any state in this case, after the interrupt is handled, the instruction that triggers a trap is re-fetched, and duly leads to an exception. In my view section 3.1.14 describes the serialization of asynchronous events.

Upvotes: 1

Related Questions