Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Tue, 18 Mar 2025 23:00:56 +0000
Organization: Rocksolid Light
Message-ID: <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>
References: <vqto79$335c6$1@dont-email.me> <53b8227eba214e0340cad309241af7b5@www.novabbs.org> <3pXAP.584096$FVcd.26370@fx10.iad> <795b541375e3e0f53e2c76a55ffe3f20@www.novabbs.org> <vNZAP.37553$D_V4.18229@fx39.iad> <aceeec2839b8824d52f0cbe709af51e1@www.novabbs.org> <eM_AP.81303$8rz3.7843@fx37.iad> <vr2nj9$2goqe$1@dont-email.me> <f2cb846242dbfcef1efa59b92763a965@www.novabbs.org> <vr4ovm$9fl5$1@dont-email.me> <1681197d3c1af131d6b8cae884f7c9ca@www.novabbs.org> <vr7g76$2jnqm$1@dont-email.me> <8BVBP.816276$eNx6.247046@fx14.iad> <20250317161132.00004dd9@yahoo.com> <1WZBP.558392$SZca.243157@fx13.iad> <vra3bv$teuf$1@dont-email.me> <ohjCP.37185$SVG3.13173@fx42.iad> <vrcqcr$3ddah$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="772244"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$2JovkDGGTI8tp1rZpQAQzeHD51QzzNcmsdM7EgCWeaukaww/PJYcm
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
Bytes: 4548
Lines: 60

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.