From: robfi680@gmail.com   
      
   On 2025-11-29 10:37 a.m., Stephen Fuld wrote:   
   > On 11/29/2025 6:29 AM, 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…   
   >   
   > A simple alternative that I have seen is to have an instruction that   
   > enables interrupts and jumps to somewhere, probably either the   
   > interrupted code or the dispatcher that might do a full context switch.   
   >   The ISR would issue this instruction when it has saved everything that   
   > is necessary to handle the interrupt and thus could be interrupted   
   > again.  This minimized the time interrupts are locked out without the   
   > need for an arbitrary timer, etc.   
   >   
   >   
   >   
   That is a decent idea. A special jump and disable interrupts instruction   
   to the next instruction might do it. The pipeline needs to be cleared of   
   the external interrupt when interrupts are disabled, and the address   
   reset. The issue then is that the interrupt gets lost, so it needs to be   
   cached somewhere so that once interrupts are enabled again it can be   
   processed. There could be multiple interrupts in the pipeline that need   
   to be cached.   
      
   Seeing as the address needs to be reset, an explicit jump instruction   
   may not be necessary. The IP of the interrupted instruction could be used.   
      
   I see now that a stack might be better than a FIFO as only a higher   
   priority interrupt would be able to interrupt the lower one. Should they   
   be processed in order of occurrence? Order of occurrence = FIFO,   
   otherwise stack = FILO. Leave it to the user to decide? Out of order   
   asynchronous interrupts probably are not a big deal. Hardware likely   
   does not know what the order is, or care about it.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)