8259 - Handling low priority IRQs before getting EOI[solved]

[shahsunny712]

Intel's manual for the 8259 PIC says the following for the "Fully Nested Mode":

While the IS bit is set all further interrupts of the same or lower priority are inhibited while higher levels will generate an interrupt (which will be acknowl-
edged only if the microprocessor internal Interupt enable flip-flop has been re-enabled through software)

So if a low priority interrupt occurs before an EOI is received, are the requests for the low priority interrupts stored in the IRR (by setting their bit) to be serviced later, or are they ignored completely ?

From what I've read, the IRR bit is set first after which IMR is checked. So assuming a low priority interrupt occurs while a high priority one is being serviced, will this happen - set IRR bit, check IMR (thus finding that the low priority interrupt is inhibited) and thus reset the IRR bit ?

[alexfru]

So if a low priority interrupt occurs before an EOI is received, are the requests for the low priority interrupts stored in the IRR (by setting their bit) to be serviced later, or are they ignored completely ?

Here's the answer:

The interrupts at the IR input lines are handled by two registers in cascade, the Interrupt Request Register (IRR) and the In-Service (ISR). The IRR is used to store all the interrupt levels which are requesting service; and the ISR is used to store all the interrupt levels which are being serviced.

The events occur as follows in an MCS-80/85 system:
1. One or more of the INTERRUPT REQUEST lines (IR7-0) are raised high, setting the corresponding IRR bit(s).
2. The 8259A evaluates these requests, and sends an INT to the CPU, if appropriate.
3. The CPU acknowledges the INT and responds with an /INTA pulse.
...
The events occuring in an 8086 system are the same until step 4.

From what I've read, the IRR bit is set first after which IMR is checked. So assuming a low priority interrupt occurs while a high priority one is being serviced, will this happen - set IRR bit, check IMR (thus finding that the low priority interrupt is inhibited) and thus reset the IRR bit ?

I don't know for sure whether or not interrupt requests from the interrupt lines that are masked via IMR are still observable in IRR. The document is a bit fuzzy here. However, setting and immediately resetting IRR based on IMR does not make much sense.

See, if IMR makes masked requests completely invisible, the simplest solution is to just do IR(n)_internal = IR(n) & !IMR(n). Nothing to set or reset, just ignore IR(n) by logically ANDing. It's the cheapest solution.

OTOH, if IR(n)/IRR is/are transparent but IMR inhibits generation of INT on certain bits in IRR by ignoring their state (again, by doing a logical AND), then by definition IMR does not affect IRR, even though it alters the behavior down the road.

IOW, either IRR always follows IRs irrespective of IMR (IMR only blocking ISR/INT) OR IMR blocks the passage of IRs to IRR and the masked lines never show up in IRR.

I don't think it matters which of the two is the case.