| |
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....
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
After all, why bother about those few wasted bytes, where's the highly optimized demo parts? :-D How can this behaviour finally be misused? By having the upcoming instruction of the SEI on a register being read or not? |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Since the succeeding opcode is merely fetched, and not executed, then the pipeline flushed and the interrupt handled, then the opcode re-fetched and finally executed...
I can only imagine some arcane anti-cracking/debugging/reverse-engineering setup there, nothing demo-worthy. |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Morale of the story is:
SEI/CLI your init. take care of unwanted IRG/NMI events from smegging up your shit. Let the byte optimizers optimize^^ |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quoting TWWMorale of the story is:
SEI/CLI your init.
You appear to have forgotten the word "don't"
Just use MagerValp's routine from comment 26, and you'll be fine. SEI/CLI does nothing but create a problem that requires additional handling. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quoting KrillSince the succeeding opcode is merely fetched, and not executed, then the pipeline flushed and the interrupt handled, then the opcode re-fetched and finally executed...
I can only imagine some arcane anti-cracking/debugging/reverse-engineering setup there, nothing demo-worthy.
Yes, you'd have to be running code stored in read-sensitive IO registers, at the precise cycle an IRQ is expected. I find it hard to imagine any kind of scenario where that would save you any cycles or memory. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quoting TWWMorale of the story is:
SEI/CLI your init.
You appear to have forgotten the word "don't"
Just use MagerValp's routine from comment 26, and you'll be fine. SEI/CLI does nothing but create a problem that requires additional handling.
good luck with that when an irq midst your interrupt setup interferes with your initialization. |
| |
lft
Registered: Jul 2007
Posts: 369 |
The only interrupt source that is enabled at program start is CIA1. And we disable all CIA1 interrupts. So where would the interference come from again? |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: The only interrupt source that is enabled at program start is CIA1. And we disable all CIA1 interrupts. So where would the interference come from again?
assumption is the root of all bugs. if you change enviroment you're facing hrs of debugging until you find the faulty non sei/cli irq setup, that relies on having the system in a known state. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
anyhow I realise this is a religious argument, everyone should just do it as he likes. doesnt really matter. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Oswald, if there's a source you don't know about to disable, you're going to have bugs regardless of whether you SEI/CLI or not, as it's going to hit while your code isn't expecting it.
And if you do know about it, you can disable it, in which case an SEI before you disable it will create extra work for you, or an SEI after you disable it will do nothing.
Either way all you are doing is adding extra bytes to your init code with zero improvements to reliability.
It may even cause your raster interrupt to have it's first occurrence on the wrong line altogether, which can occasionally produce a frame of garbage at the start of your routine. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
