| |
Krill
Registered: Apr 2002
Posts: 2821 |
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....
|
| |
White Flame
Registered: Sep 2002
Posts: 136 |
The 6502 implemented delay slots before delay slots were cool. ;-) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
well it makes sense 6502 have a kind of prefetch. guess hardwired behaviour doesnt wants to drop the instructions before executed. |
| |
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: 11089 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
