From: robfi680@gmail.com
On 2025-11-29 6:14 p.m., MitchAlsup wrote:
>
> Robert Finch posted:
>
>> On 2025-11-29 4:10 p.m., EricP wrote:
>>> Robert Finch wrote:
>>>> I hard-coded an IRQ delay down-count in the Qupls4 core. The down-
>>>> count delays accepting interrupts for ten clock cycles or about 40
>>>> instructions if an interrupt got deferred. The interrupt being
>>>> deferred because interrupts got disabled by an instruction in the
>>>> pipeline. I guessed 40 instructions would likely be enough for many
>>>> cases where IRQs are disabled then enabled again.
>>>>
>>>> The issue is the pipeline is full of ISR instructions that should not
>>>> be committed because the IRQs got disabled in the meantime. If the CPU
>>>> were allowed to accept another IRQ right away, it could get stuck in a
>>>> loop flushing the pipeline and reloading with the ISR routine code
>>>> instead of progressing through the code where IRQs were disabled.
>>>>
>>>> I could create a control register for this count and allow it to be
>>>> programmable. But I think that may not be necessary.
>>>>
>>>> It is possible that 40 instructions is not enough. In that case the
>>>> CPU would advance in 40 instruction burps. Alternating between
>>>> fetching ISR instructions and the desired instruction stream. On the
>>>> other hand, a larger down-count starts to impact the IRQ latency.
>>>>
>>>> Tradeoffs…
>>>>
>>>> I suppose I could have the CPU increase the down-count if it is
>>>> looping around fetching ISR instructions. The down-count would be
>>>> reset to the minimum again once an interrupt enable instruction is
>>>> executed.
>>>>
>>>> Complex…
>>>>
>>>
>>> You are using this timer to predict the delay for draining the pipeline.
>>> It would only take a read of a slow IO device register to exceed it.
>>>
>> The down count is counting down only when the front-end of the pipeline
>> advances, instructions are sure to be loaded.
>>
>>> I was thinking a simple and cheap way would be to use a variation of the
>>> single-step mechanism. An interrupt request would cause Decode to emit a
>>> special uOp with the single-step flag set and then stall, to allow the
>>> pipeline to drain the old stream before accepting the interrupt and
>>> redirecting Fetch to its handler. That way if there are and interrupt
>>> enable or disable instructions, or branch mispredicts, or pending
>>> exceptions
>>> in-flight they all are allowed to finish and the state to settle down.
>>>
>>> Pipelining interrupt delivery looks possible but gets complicated and
>>> expensive real quick.
>>>
>>>
>>>
>> The base down count increases every time the IRQ is found at the commit
>> stage. If the base down count is too large (stuck interrupt) then an
>> exception is processed. For instance if interrupts were disabled for
>> 1000 clocks.
>>
>> I think the mechanism could work, complicated though.
>>
>> Treating the DI as an exception, as mentioned in another post would also
>> work. It is a matter then of flushing the instructions between the DI
>> and ISR.
>
> Which is no different than flushing instructions after a mispredicted branch.
Got fed up with trying to work out how get interrupts working. It turns
out to be more challenging than I expected, no matter which way it is
done. So, I decided to just poll for interrupts, getting rid of most of
the IRQ logic. I added a branch-on-interrupt BOI instruction that works
almost the same way as every other branch. Then the micro-op translator
has been adapted to insert a polling branch periodically. It looks a lot
simpler.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
