Re: MSI interrupts

On 2025-03-19 1:07 p.m., EricP wrote:

Robert Finch wrote:

>
I am going for a simple approach. Since the CSR instruction is used to manipulate the interrupt enable bits in the status register, if there is any CSR instruction in the pipeline, then interrupts will be masked off until the CSR clears. One issue with this type of approach is evil software could issue a lot of CSRs preventing interrupt servicing from happening. I Could fine tune the decode to sort out CSRs just affecting the interrupt flags. It always seems to be more logic.

 KISS is usually best - just single step the major actions.
 I added single step to my uArch with a NotifyDecode flag in the uOp.
To single step Decode emits a special nop uOp with a NotifyDecode bit
and sets a Stop flip-flop that stalls Decode. The Fetch buffer fills up
and Fetch stalls itself. When the special nop reaches Retire we know all
older instructions are done. Retire sees the NotifyDecode bit and pulses
a wire that clears the Decode Stop FF.
 Decode then emits the single step instruction uOp again with the
NotifyDecode bit and sets its Stop FF. When that uOp reaches Retire
it pulses the wire and clears the Decode Stop flag, which reads the
Fetch buffer and restarts the front end.
 

Crafty.
I have not implemented single-step yet; there is a bit in the status register for this, but I have been debugging with the CPU operating in SERIALIZE mode, which executes instructions one-at-a-time. Instead of stalling the pipeline, in the scheduler it checks if the previous instruction is done yet, if it is not done, then the next instruction does not issue. So SERIALIZE operates the pipeline in a one-way fashion. The done check is done with a parameter, so it does cause code to be modified. I suppose this could be made another status register option. Found a lot of bugs using SERIALIZE, but maybe time to add single-stepping.