Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Microarchitectural support for counting
Date: Wed, 1 Jan 2025 00:34:44 +0000
Organization: Rocksolid Light
Message-ID: <b8760a721775ebc2e1f232c2edae4be9@www.novabbs.org>
References: <2024Oct3.160055@mips.complang.tuwien.ac.at> <vdmrk6$3rksr$1@dont-email.me> <LyELO.69485$2nv5.62232@fx39.iad> <TdWLO.282116$FzW1.158190@fx14.iad> <963a276fd8d43e4212477cefae7f6e46@www.novabbs.org> <8IcMO.249144$v8v2.147178@fx18.iad> <vkhgkn$2g9gm$1@dont-email.me> <7bffca4c284d329c60d8e93c7382c30f@www.novabbs.org> <vl1nr6$2diq8$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1414279"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Rslight-Site: $2y$10$OpXRbdfdNl2F6SRAAMiAiObfzTWTKy0qNq/5IOOi78/NDhJEDF4VC
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3876
Lines: 63

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.