Re: Microarchitectural support for counting

On Tue, 31 Dec 2024 2:02:05 +0000, Paul A. Clayton wrote:

On 12/25/24 1:30 PM, MitchAlsup1 wrote:

On Wed, 25 Dec 2024 17:50:12 +0000, Paul A. Clayton wrote:
>

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

MitchAlsup1 wrote:

[snip]

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

>

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.

>
It depends on what you mean::
>
a) if you mean that exceptions are prioritized and the highest
priority exception is the one taken, then OK you are working
in an ISA that has multiple exceptions per instruction. Most
RISC ISAs do not have this property.

>
The context was any exception taking priority over an interrupt
that was accepted, at least on a speculative path. I.e., the
statement would have been more complete as "Should exceptions
always (or ever) have priority over an accepted interrupt?"

In the parlance I used to document My 66000 architecture, exceptions
happen at instruction boundaries, while interrupts happen between
instructions. Thus CPU is never deciding between an interrupt or an
exception.
Interrupts take on the priority assigned at I/O creation time.
{{Oh and BTW, a single I/O request can take I/O exception to
GuestOS, to HyperVisor, can deliver completion to assigned
supervisor (Guest OS or HV), and deliver I/O failures to
Secure Monitor (or whomever is assigned)}}
Exceptions take on the priority of the currently running thread.
A page fault at priority min does not block any interrupt at
priority > min. A page fault at priority max is not interruptible.
--------------------------------------

>
Sooner or later an ISR has to actually deal with the MMI/O
control registers associated with the <ahem> interrupt.

>
Yes, but multithreading could hide some of those latencies in
terms of throughput.

EricP is the master proponent of finishing the instructions in the
execution window that are finishable. I, merely, have no problem
in allowing the pipe to complete or take a flush based on the kind
of pipeline being engineered.
With 300-odd instructions in the window this thesis has merit,
with a 5-stage pipeline 1-wide, it does not have merit but is
not devoid of merit either.