I can't imagine a viable use-case for re-entrant interrupts, personally. All interrupt handlers I've seen written, and all that I've written myself, basically involves executing the following steps:
Code:
1. Determine source of interrupt
2. Record an event of some kind indicating what happened.
3. Return as fast as I possibly can.
The idea here is to let non-interrupt code deal with the interrupt. Step 2 might read data from various hardware registers to facilitate this (e.g., reading a byte from a keyboard or RS-232 FIFO), but the idea remains the same.
Eliminating the reentrancy, you will need to write your interrupt service routine as a coroutine rather than a subroutine:
Code:
ISR_EXIT:
RTI ; return to user program, including CPU state.
; When an interrupt triggers again, execution picks up here.
ISR_ENTRY:
JSR isItVia1
JSR isItVia2
JSR isItAcia
JMP ISR_EXIT
Access to user-mode state (e.g., the interrupted program's registers) can be done through special memory locations visible only to the interrupt handling code.
Alternatively, if you prefer the subroutine model, you can just have an interrupt force-load PC with a special I_PC register value, and save the PC in R_PC or some such. That way, if you want re-entrancy, you can do this:
Code:
ISR_ENTRY:
PHR ; push R_PC
PHF ; push R_P (user "f"lags)
SEI ; re-enable interrupts
...process normally, including explicitly saving any other state...
PLF
PLR
RTI
_RESET:
...etc...
LDA #ISR_ENTRY
PHA
PLI ; load I_PC register -- safe to enable IRQ now.
...etc...