Re: MSI interrupts

On Tue, 18 Mar 2025 21:59:51 +0000, Robert Finch wrote:

On 2025-03-18 2:51 p.m., EricP wrote:

----------------

Would it not be rare for this to occur? If so, I think the pipeline
could just be flushed from the int disabling instruction on. Then the
interrupted address recorded as the int disabling instruction. <- this
requires identification of an int disabling instruction though. It
might just be a store to a specific I/O address, therefore a special
store opcode to make it easy to detect?

>
It likely is rare but the possibility that the existing instructions,
a branch mispredict or an exception throw, could retroactively change
the state of the interrupt enable flag to disabled creates this
Window of Uncertainty (WoU) that is the length of the pipeline.
>
Unless one can find a way to make WoU go away the ICU needs to deal
with the possibility that there could be hundreds of clocks between
when ICU asks a core if it can accept an interrupt and when the core
does.
>
I had a few ideas walking in the park yesterday. I had been assuming
that
when an exception is delivered that it would also automatically disable
interrupts. That may not be a good idea as it means that any instruction
that can throw an exception could cause this retroactive disabling.
>
If I remove that exception side effect then the only things that can
manipulate the core's master Interrupt Enable flag are the enable INTEN
and disable INTDI instructions, and the actual delivery of an interrupt.
And those three things can be tracked with a counter in Decode as they
move down the pipeline to Retire. If the counter >0 then there is a
flag change in flight and we don't accept a new interrupt. When count ==
0
and Interrupt Enable flag == 1 then core accepts interrupts, which are
injected at Decode and cause a light weight purge of the Fetch buffer.
>

Seems like it could work. There are difficulties using counters with the
Q+ ISA as multiple interrupt enable bits could be manipulated at the
same time. One interrupt may be enabled and another one disabled by the
same instruction.

I want to address the elephant in the room::
Why disable interrupts AT ALL !!
When running at any privilege, do you not want to accept an interrupt
at higher priority with as little delay as possible ??
Does Interrupt Disable help in this goal ??
Is there a SANE way to avoid disabling of interrupts ??
So, what does it take to take (sic) interrupts without disabling
interrupts ?? It takes the interrupt control transfer sequence
to leave the core in an interruptible state ! {{Same for exceptions}}
My 66000 interrupt negotiator will not negotiate for interrupts
at the same or lower priority the core is currently running.
This is done by using the 6-bit priority as a less-than mask
generator across the current-raised 64-bit control register.