kasanovic
commented
3 years ago To clarify:
This provides a single instruction "transient enable" of interrupts pending to allow them to be taken at this point in code, while before or after this instruction interrupts are disabled.
The instruction acts as a NOP, except that interrupts are temporarily globally enabled for duration of instruction. The instruction does not change state, so if interrupts were enabled, they remain enabled afterwards.
epc should point at the "transient enable" instruction, may get re-executed. Value in xstatus.xpie would be that in xstatus.xie at time of interrupt.
Pros: this reduces code size and improves performance Cons: implementation complexity
Does not directly relate to nxti but this is a space in the encoding that is otherwise of no use.
currently transition from one critical section to the next requires two instructions: csrrsi x0, mstatus, MIE # Enable interrupts. csrrci x0, mstatus, MIE # Disable interrupts.
This back to back sequence could be fused to a 64bit single instruction interrupt window that pending horizontal interrupts would use.
However, many fast-interrupt processors will not include the infrastructure to fuse instructions as the net result would be a slowdown of the "simple" design.
I propose this "fused instruction" be an explicit variant of the xnxti csr that would otherwise provide no use purpose.
Specifically, csrrw x0,xnxti,x0 will 1) as is current convention with instructions with X0 as source, not directly change any csr state. 2) for only the duration of the instruction, pending horizontal interrupts will be enabled.
This has the combined benefit of providing a window for pending interrupts between critical code sections and eliminating the power usage of two cs state transitions, and reducing handler time.
The usage may confuse those who assumed xnxti was exclusively intended to avoid interrupt overheads, but it does fit in neatly with the idea of managing the horizontal interrupts.