home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.arch      Apparently more than just beeps & boops      131,241 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 130,392 of 131,241   
   Stephen Fuld to Robert Finch   
   Re: Interrupt enable down-count   
   29 Nov 25 07:37:20   
   
   From: sfuld@alumni.cmu.edu.invalid   
      
   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.   
      
      
      
   --   
     - Stephen Fuld   
   (e-mail address disguised to prevent spam)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca