Hi Philipp, I also think 3) is correct.
And I think you misread the manual. It states that a non-interruptable ISR uses __critical __interrupt(0). This means that 1) needs an extra EI in the entry. This was supposed to be an interruptible ISR. When I implemented it I think I forgot that entering the ISR automatically disables interrupts and that RETI does not enable interrupts. Probably too much time spent with the mcs51 ;) If the Z80 is accompanied by a genuine Z80 peripheral like the CTC, DMA, PIO or SIO with cascaded interrupt daisy-chain the INT Acknowledge will remove the /INT request, so an EI will not immediately lead to another triggering of an interrupt. But if the peripheral does not adhere to this scheme things can go wrong. This latter case will require a non-interruptible ISR. The keyword __critical seems appropriate here to make the ISR an atomic action. This is what was the idea behind 2), to disable all interrupts on entry and re-enable them at exit. So the bug is that 1) needs an EI in the entry (not the exit) and that 2) doesn't need a DI. Maarten > I had a look at bug reports https://sourceforge.net/p/sdcc/bugs/2131/ > and https://sourceforge.net/p/sdcc/bugs/2339/ and section "3.8.4 Z80 > Interrupt Service Routines" in the manual. > > According to the manual, we have: > 1) non-interruptible isr (can be interrupted by nmi only): > void i1(void) __interrupt > 2) interruptible isr (can be interrupted by any interupt) > void i2(void) __critical __interrupt(0) > 3) nmi handler (can be interrupted by nmi only) > void i3(void) __critical __interrupt > > We generate code: > 1) > save regs > ... > restore regs > reti > 2) > di > save regs > ... > restore regs > ei > reti > 3) > save regs > ... > restore regs > retn > > Out of these, 3) looks correct to me. But 1) fails to reenable > interrupts at the end (I think there should be an ei before the reti). > And 2) is completly wrong, I think it should be: > ei > save regs > ... > restore regs > reti > > Did I miss something? > > Philipp > (who so far always wrote his interrupt handlers in asm instead of using > the SDCC-provided facilities) ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user