From: robfi680@gmail.com   
      
   On 2025-11-29 2:05 p.m., MitchAlsup wrote:   
   >   
   > Robert Finch  posted:   
   >   
   >> 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.   
   >   
   > The above is one of the reasons EricP supports the pipeline notion that   
   > interrupts do NOT flush the pipe. Instead, the instruction in the pipe   
   > are allowed to retire (apace) and new instructions are inserted from   
   > the interrupt service point.   
      
   That is how Qupls is working too. The issue is what happens when the   
   instruction in the pipe before the ISR disables the interrupt. Then the   
   ISR instructions need to be flushed.   
      
   As long as the instructions "IN" the pipe   
   > can deliver their results to their registers, and update µArchitectural   
   > state they "own", there is no reason to flush--AND--no corresponding   
   > reason to delay "taking" the interrupt.   
      
   That is the usual case for Qupls too when there is an interrupt.   
   >   
   > At the µArchitectural level, you, the designer, see both the front   
   > and the end of the pipeline, you can change what goes in the front   
   > and allow what was already in the pipe to come out the back. This   
   > requires dragging a small amount of information down the pipe, much   
   > like multi-threaded CPUs.   
   >   
   Yes, the IRQ info is being dragged down the pipe.   
      
   >> 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…   
   >>   
   > Make the problem "go away". You will be happier in the end.   
      
   The interrupt mask is set at fetch time to disable lower priority   
   interrupts. I suppose disabling of interrupts by the OS could simply be   
   ignored. The interrupt could only be taken if it is a higher priority   
   than the current level.   
      
   I had thought the OS might have good reason to disable interrupts. But   
   maybe I am making things too complex.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)