From: user5857@newsgrouper.org.invalid   
      
   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)