| |
Krill
Registered: Apr 2002 Posts: 2825 |
TIL: The instruction after SEI can be executed before a pending IRQ is handled
As described here: http://visual6502.org/wiki/index.php?title=6502_Timing_of_Inter..
I never knew this, after all those years, and thought i'd share this as a heads-up.
Thanks to Bubis for pointing it out to me! |
|
... 89 posts hidden. Click here to view all posts.... |
| |
lft
Registered: Jul 2007 Posts: 369 |
This could lead to horrible bugs indeed, if sei/cli are used around critical sections (like Disable/Enable are often used in AmigaOS).
It's kind of neat that when this happens, the status register gets pushed with the I bit set. That way, RTI will correctly restore an environment in which interrupts are disabled. |
| |
doynax Account closed
Registered: Oct 2004 Posts: 212 |
Yet an RTI leaving the IRQs unacknowledged does not single-step. Evidently there is either or two cycles of pipelining involved.
I wonder though, is it possible to prove one cycle of latency in the mask register short of cheating with visual6502? Which of the PLP read cycles is the dummy one?
Incidentally this is common a number of architectures and the reason why interrupt barriers exist. |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1370 |
Wait, so if I understand that correctly if I have
SEI
{instruction1}
{instruction2}
it's possible to get an interrupt *between* instructions one and two?
That could be Bad :(
Thanks for the heads up. |
| |
JackAsser
Registered: Jun 2002 Posts: 1987 |
So, always nop after sei? :) |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1370 |
Eh, anything that doesn't access any memory outside the instruction stream should be fine.
Though if you're being really evil one might have to also remember to avoid using your interrupt handler to modify the instruction immediately following the SEI... |
| |
chatGPZ
Registered: Dec 2001 Posts: 11100 |
yet another reason to forget this cargo cult of putting sei/cli around raster irq setup :) |
| |
MagerValp
Registered: Dec 2001 Posts: 1055 |
I think you're reading the trace wrong. The next instruction following an SEI can be fetched, but not executed if an IRQ occurs during the SEI. The instruction will be re-fetched and executed following the RTI.
And yes, protecting IRQ setup with SEI/CLI is still wrong, but not for this reason :) |
| |
Dano
Registered: Jul 2004 Posts: 226 |
Quote: I think you're reading the trace wrong. The next instruction following an SEI can be fetched, but not executed if an IRQ occurs during the SEI. The instruction will be re-fetched and executed following the RTI.
And yes, protecting IRQ setup with SEI/CLI is still wrong, but not for this reason :)
Sorry for being offtopic there, but why is putting the IRQ setup into SEI/CLI wrong? Doesn't this ensure that no IRQ is happening while setting up the shizzle? I am happy to be enlighted on how to do this correctly. |
| |
TWW
Registered: Jul 2009 Posts: 541 |
Quote: Sorry for being offtopic there, but why is putting the IRQ setup into SEI/CLI wrong? Doesn't this ensure that no IRQ is happening while setting up the shizzle? I am happy to be enlighted on how to do this correctly.
What he said |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1370 |
Quoting MagerValpI think you're reading the trace wrong. The next instruction following an SEI can be fetched, but not executed if an IRQ occurs during the SEI. The instruction will be re-fetched and executed following the RTI.
Ok, that makes a lot more sense. |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |