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