From: user5857@newsgrouper.org.invalid   
      
   Robert Finch  posted:   
      
   > 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 a general rule of thumb:: an instruction is not "performed" until   
   after it retires. {when you cannot undo its deeds}   
      
   Consider the case where you redirect the front of the pipe to an ISR and   
   an instruction already in the pipe raises an exception. Here, what I do   
   {and have done in the past} is to not retire instructions after the   
   exception, so the ISR is not delayed and IP ends up pointing at the   
   excepting instruction.   
      
   Since you started ISR before you retired DI, you can treat DI as an   
   exception. {DI after ISR control transfer}. If, on the other hand,   
   you perform DI at the front of the pipe, you don't "accept" the ISR   
   until EI.   
      
   > > 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.   
   >   
      
   The OS DOES have good reasons to DI "every once in a while", IIRC my   
   conversations with EricP, these are short sequences the OS needs   
   to be ATOMIC across all OS threads--and almost always without the   
   possibility that the ATOMIC event fails {which can happen in user code}.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)