Following on to https://github.com/riscv/riscv-isa-manual/pull/701.

There should be more said that there's no expectation of implementations "edge detecting" the "becomes pending" event.  For example, runt interrupt assertions may be observable (via read of pending state) on an enabled interrupt and it's possible that no interrupt trap is ever taken.  Or is the intent different?

The specification should consider the other edge as well.  When an interrupt is observed to deassert its pending state, what is the bound on the interrupt still causing a trap?

Is a write to mstatus also synchronizing (due to presence of MIE)?

Is it intentional to leave out writes to other "upstream logic" regarding interrupt enable and pending state, such as that in the AIA IMSIC?

It may be transitive, but for my understanding, due to "Synchronous exceptions are of lower priority than all interrupts.", taking an exception will also cause the observed-pending-and-enabled interrupt trap to occur immediately (e.g., executing EBREAK).  Correct?

-Josh

On Tue, Aug 10, 2021 at 6:03 PM Josh Scheid <jscheid@...> wrote:

Following on to https://github.com/riscv/riscv-isa-manual/pull/701.

There should be more said that there's no expectation of implementations "edge detecting" the "becomes pending" event.  For example, runt interrupt assertions may be observable (via read of pending state) on an enabled interrupt and it's possible that no interrupt trap is ever taken.  Or is the intent different?

The specification deliberately permits the possibility that runt interrupt pulses are temporarily visible in *ip but do not cause a trap.  This doesn't seem to be ambiguous under the current wording.

 

It may be transitive, but for my understanding, due to "Synchronous exceptions are of lower priority than all interrupts.", taking an exception will also cause the observed-pending-and-enabled interrupt trap to occur immediately (e.g., executing EBREAK).  Correct?

I don't agree that that follows, since the implementation still has freedom to defer the taking of interrupt traps until a synchronizing event, and e.g. executing an EBREAK is not defined to be a synchronizing event.

The purpose of the sentence you quoted is to specify the behavior _following_ a synchronizing event.  For example, if S-mode software sets sip.SSIP and sie.SSIE and then executes an SRET to return to U-mode, and then a page fault occurs in fetching the instruction pointed to by sepc, then the implementation must take the interrupt trap instead of the page fault.

In what way does "Synchronous exceptions are of lower priority than all interrupts." have unique additional normative value now that the "evaluated immediately following [synchronizing instructions]" statements are in place?  Just to additionally clarify what "immediately" means?

On Tue, Aug 10, 2021 at 9:34 PM Andrew Waterman <andrew@...> wrote:

On Tue, Aug 10, 2021 at 6:03 PM Josh Scheid <jscheid@...> wrote:

Following on to https://github.com/riscv/riscv-isa-manual/pull/701.

There should be more said that there's no expectation of implementations "edge detecting" the "becomes pending" event.  For example, runt interrupt assertions may be observable (via read of pending state) on an enabled interrupt and it's possible that no interrupt trap is ever taken.  Or is the intent different?

The specification deliberately permits the possibility that runt interrupt pulses are temporarily visible in *ip but do not cause a trap.  This doesn't seem to be ambiguous under the current wording.

I think it allows for edge-detect hidden state implementations.  This and the negedge issue that you passed over can be accommodated by changing

"""

These conditions for an interrupt trap to occur must be evaluated in a bounded
amount of time from when an interrupt becomes pending in {\tt mip},

"""

to something like

"""

These conditions for an interrupt trap to occur must be evaluated in a bounded
amount of time from when an interrupt pending state changes in {\tt mip},

"""

 

It may be transitive, but for my understanding, due to "Synchronous exceptions are of lower priority than all interrupts.", taking an exception will also cause the observed-pending-and-enabled interrupt trap to occur immediately (e.g., executing EBREAK).  Correct?

I don't agree that that follows, since the implementation still has freedom to defer the taking of interrupt traps until a synchronizing event, and e.g. executing an EBREAK is not defined to be a synchronizing event.

The purpose of the sentence you quoted is to specify the behavior _following_ a synchronizing event.  For example, if S-mode software sets sip.SSIP and sie.SSIE and then executes an SRET to return to U-mode, and then a page fault occurs in fetching the instruction pointed to by sepc, then the implementation must take the interrupt trap instead of the page fault.

That confirms for me that exceptions are not synchronizing with respect to interrupt pending state.  This was not clear.

In what way does "Synchronous exceptions are of lower priority than all interrupts." have unique additional normative value now that the "evaluated immediately following [synchronizing instructions]" statements are in place?  Just to additionally clarify what "immediately" means?

-Josh