04/01/11: Interrupt Routine Reentrancy by sc, | Category: Programming | 8 comments - (Comments are closed)

Interrupt Routine Reentrancy

I am assuming that after my IRQ fires, and I’ve checked $FF92 to see what the source was, and then jumped to my service routine, that while I am doing my processing (before I’ve called RTI) the same interrupt could fire again, causing reentrancy problems and blowing up my stack.  Is it acceptable to call ORCC #$50 at the beginning of an interrupt service routine, and ANDCC #$AF at the end, in order to disable interrupts during processing?  Or would this cause problems?

8 comments to Interrupt Routine Reentrancy

  • Robert Gault

    That should not normally be necessary as “the 6809 automatically disables the regular interrupt as part of its normal response.” Lance A. Leventhal

    The GIME is slightly different from the PIAs so interrupts can be handled in a slightly different manner. While the CPU will not respond to an interrupt while servicing another, the GIME can store an interrupt signal that arrives during processing of another. In OS-9, there is now a toggle in the clock module to retrieve such stored interrupts.
    You can study the code for NitrOS-9 at Sourceforge.

  • beretta42

    Mr Gault is correct. On reception of an interrupt, the M6809 modifies (depending on the kind of interrupt) the E bit of CC, stacks some of it’s registers (again depending on the kind of interrupt), and always stacks the CC register (last). The the M6809 proceeds to mask I and F (again depending on which interrupt), and fetch the interrupt vector from the 0xFFF0 paragraph. This happend atomically, and no new interrupts will be serviced until the 6809 goes to fetch the firth OP code of your handler. Your interrupt code is ran and you “RTI”, RTI will proceed to restore the I and F bits (well the whole CC register, actually), and reloads any registers it stacked (thanks to the saved E bit in CC )… The 6809 does this for all “free” (well… 28 cycles + “free” )

    Robert’s also correct that most (all?) of the CoCo’s hardware interrupts are “latched” by the PIA chips or the GIME, and hence the CoCo is able to “store” up to 1 interrupt from the same source.

    Interrupts are very confusing, as there’s several hardware parts all working together to handle interrupts. The GIME’s and PIA’s interrupt can be enabled and disabled, they are both latched, and work, confusingly, in parallel with each other. The PIA’s can also be set to handle “positive-going” interrupts from sources, also. The sources themselves can have interrupt settings (like TIMER or the FDC ). I particularly like the oxymoron of Tandy’s disk controller having a maskable-non-maskable-interrupt ?!?!?!

  • sc

    So it sounds like a FIRQ could interrupt the IRQ handling routine and vice versa?

  • Robert Gault

    For the 6809, an incoming IRQ disables the CPU response to additional IRQs. An incoming FIRQ disables the CPU response to both additional IRQs and FIRQs.
    That means an FIRQ could break into an IRQ routine but not vice versa.

    With the Coco3 GIME interrupts, I’ve not seen this explicitly described anywhere. It certainly is not in the Tandy Coco3 service manual. One would hope that for consistency with the 6809, the GIME would have the same format.

    Be that as it may, if you have any doubts or concerns, good programing practice would be to kill CPU response to further interrupts at the beginning of a service routine by turning off interrupt response with regCC.
    Turn interrupts back on at the end of the service routine.

    In practice, whether you need to turn off interrupts will depend whether you are polling interrupts or using an automatic response.
    As with most questions of this nature, they can’t be answered without seeing specific code. If you are at the point of discussing specific code, then you should already have tested it under as many conditions as possible and will therefore have experimentally found the answer on your own. :)

  • pilot352

    I know in my past 6809 Engineering days (seems like an eternity ago)we would re-enable the IRQ as the first duty in the ISR. Not pertinent to the CoCo but if we didn’t do that we would drop interrupts and cause system problems. There’s no interrupt latch cache’ so if an interrupt came in… buh bye.

    Also it was noted (again not related to the CoCo) but the 6809 NMI is level triggered as opposed to edge triggered like the IRQ/FIRQ. If your NMI routine is shorter than the NMI pulse coming in, the 6809 goes into a holding pattern until the NMI is released. We found this when we realized our loop time was excessively long. We ran a 500ms square to the NMI. The processor locked up for 250ms.

    Oh the fun days!!! LMAO!

  • DarrenA

    Actually, you have that backwards. IRQ and FIRQ are level triggered while NMI is edge triggered. This makes sense since IRQ and FIRQ set the corresponding mask(s) on invocation preventing further interruption until the service routine allows it. NMI, as its name implies, is not maskable and must be edge triggered to avoid continuous interruption.

    • pilot352

      I just checked and you are correct the specs do say that in a vague way. But, there was some strange behavior with the NMI where if it was held low after reset and stack load, the processor would effectively freeze. It was almost 25 years ago, so the details are sketchy. I just remember we had to redesign a section of our hardware to correct the problem by keeping the NMI pulse width very small. I guess that’s why I remember it being level triggered.

      I hate getting old. I got CRS disease. (Can’t Remember Shit).

      • pilot352

        …also, we used a MC68B09 vs the 6809E. It may have some influence on what we saw. Anyway… next topic.