I am studying an FLI routine in http://codebase64.org/doku.php?id=base:fli_displayer and I noticed that the CLI instruction is being used in this IRQ routine:
irq0: pha
...
cli ; <<< ???
nop
nop
nop
nop
...
pla
rti
As I know it probably does not have any effect on the IRQ routine. Or does it?
Without issuing a CLI, no further interrupts can occur (until EOI, at least, where flags are restored by the RTI instruction). As this is a raster interrupt, you need to acknowledge that as well for another one to happen, which the seemingly benign $D019 manipulation achieves earlier in the interrupt handler, cf. the linked FLI routine.
In this specific case, the idea is to let the raster interrupt occur again, while still being in the "outer" raster interrupt handler, such that the "inner" trigger will be interrupting a stream of NOPs.
The interrupt cannot happen in the middle of the CPU executing an instruction and gets deferred to the end of the current instruction. The clock cycles needed by various instructions the CPU might be executing at the point of interrupt varies, but knowing that what's interrupted is a NOP (2 clock cycles) means the timing of the raster interrupt at this point is much more predictable (only 1 cycle jitter possible).
Any jitter in the raster IRQ timing is unacceptable for most advanced VIC effects on the C64, so most will include a similar kind of raster stabilization.
As I know it probably do not any effect on IRQ routine. Or do it?
No, it does not. Well, it does, but that depends.
Before entering an interrupt routine the interrupt disable flag (I) is set, preventing the CPU from accepting other interrupts so it can setup the environment needed to do its job without being interrupted again. Basically an implied SEI, creating a semaphore (lock) around the (start of) the interrupt routine.
It is (as always) good practice to keep locked sections as short as possible. So as soon as a routine has established itself and gathered whatever data is necessary to be collected undisturbed, for example detecting the source, it should enable interrupts again. After this, other interrupt sources can get served in parallel.
Of course, all of this depends on the structure of the whole system, the program(s) in control, the number of concurrent interrupts and the like.
Without knowing more of either it's impossible to say if there are effects or not.
