On Wed, 24 May 2006, Erik Scharwaechter wrote:
I see, so the PIC seems to have a tracking mechanism similar to the
queue I proposed. Now, I'm wondering how the PIC notices that the IF
flag is reset to 1 again. Is it done with a trial-and-error method by
sending these pending interrupts over and over again until they have
been honoured by the CPU? Or is there an additional line between the PIC
and the CPU to indicate the state of this flag?
I think there is something fundamentally wrong about this reasoning. I
don't have a lot of experience with x86 processors I'll admit (but hoping
to learn), but normally an interrupt goes about like this:
- The device wanting to interrupt the CPU activates the interrupt line.
- CPU detects interrupt line is active and (eventually) calls the
interrupt routine.
- Interrupt routine acknowledges the interrupt by writing to the device
when makes the device release the interrupt line.
Thus the device does not 'resend the interrupt', rather it keeps its
interrupt line activated until told to release it. For instance,
a serial port UART (lets assume with no fifo for simplicity) will activate
the interrupt line as soon as a character is recieved. Reading the
character from the receive buffer of the UART will clear the interrupt
line. (Normally there is some sort of masking control in the UART so that
the interrupt line can be disabled if necessary).
Thus, an interrupt cannot be lost by the CPU disabling its interrupt flag;
it will simply occur when interrupts are later enabled. (An exception
would be a device that for some reason releases its interrupt line
prematurely, perhaps because the condition that caused the interrupt has
gone away.) The situation is basically the same as if several interrupts
occurred at the same time; the interrupt controller will have to perform
some sort of prioritizing in any case.
I'm not sure how an interrupt controller such as an 8259-compatible or
newer device affects this. I seem to recall reading somewhere that the
interrupt input on x86 CPU's are edge sensitive rather than level
sensitive, which throws the above reasoning off a bit (and makes low level
interrupt programming awkward at best). One (theoretical) solution would
be for the interrupt controller to toggle the interrupt line to the CPU at
some frequency to repeatedly cause interrupts until the CPU reacts. I'd be
happy if anyone could shed any light on this, although we are getting far
from the kernel and dangerously close to the bare metal here.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
