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

Reply via email to