Re: Microarchitectural support for counting

On 10/5/24 11:11 AM, EricP wrote:

MitchAlsup1 wrote:

[snip ROB clearing for branch mispredict with following interrupt]

Not necessary, you purge all of the younger instructions from the
thread at retirement, but none of the instructions associated with
the new <interrupt> thread at the front.

 That's difficult with a circular buffer for the instruction queue/rob
as you can't edit the order. For a branch mispredict you might be able
to mark a circular range of entries as voided, and leave the entries
to be recovered serially at retire.

One might also invert the order of ROB insertion for the interrupt
thread, starting at the tail of the earlier thread and progressing
toward and through the head of the earlier thread (the
instructions canceled by the misprediction).
This has the disadvantage of not allowing the new thread to use
old ROB entries from the earlier thread until all instructions in
the earlier thread have committed. If mispredictions and
exceptions were handled only at commitment/retirement, there would
be no such old entries. If a misprediction is handled before
retirement, there generally would be earlier instructions/ROB
entries that are not yet freeable.
Another possibility is to use a circular buffer of pointers to ROB
chunks. I think some SMT implementations did this to provide
finer-grained resource sharing.

But voiding doesn't look like it works for exceptions or conflicting
interrupt priority adjustments. In those cases purging the interrupt
handler and rejecting the hand-off looks like the only option.

Should exceptions always have priority? It seems to me that if a
thread is low enough priority to be interrupted, it is low enough
priority to have its exception processing interrupted/delayed.
(There might be cases where normal operation allows deadlines to
be met with lower priority and unusual extended operation requires
high priority/resource allocation. Boosting the priority/resource
budget of a thread/task to meet deadlines seems likely to make
system-level reasoning more difficult. It seems one could also
create an inflationary spiral.)
With substantial support for Switch-on-Event MultiThreading, it
is conceivable that a lower priority interrupt could be held
"resident" after being interrupted by a higher priority interrupt.
A chunked ROB could support such, but it is not clear that such
is desirable even ignoring complexity factors.
Being able to overlap latency of a memory-mapped I/O access (or
other slow access) with execution of another thread seems
attractive and even an interrupt handler with few instructions
might have significant run time. Since interrupt blocking is
used to avoid core-localized resource contention, software would
have to know about such SoEMT.
(Interrupts seem similar to certain server software threads in
having lower ILP from control dependencies and more frequent high
latency operations, which hints that multithreading may be
desirable.)

If one can live with the occasional replay of an interrupt hand-off and
handler execute due to mispredict/exception/interrupt_priority_adjust
then the interrupt pipelining looks much simplified.

Like with multiple-instruction ROB entries, replay is a useful
mechanism for managing complexity and resource use in the common
case. Exploiting instruction reuse is sort of a complement;
increasing complexity to avoid re-execution of both-path
instructions