Interrupts: Difference between revisions
m
Link fixes
[unchecked revision] | [unchecked revision] |
No edit summary |
m (Link fixes) |
||
Line 3:
== Interrupts in a nutshell.==
An interrupt is a message from a device, such as the keyboard, to the CPU, telling it to immediately stop whatever it is currently doing and do something else. For example, the keyboard controller sends an interrupt when a key is pressed. To know what to do when a specifc interrupt arise, the CPU has a table called the
int 80h
Line 11:
==From the keyboard's perspective:==
Basically, when a key is pressed, the keyboard controller tells a device called the [[PIC|Programmable Interrupt Controller
The OS is supposed to handle the interrupt by talking to the keyboard, via
==From the PIC's perspective:==
There are actually two PICs on most systems, and each handles 8 different interrupts. Actually, IRQ 2 and IRQ 9 (handled by the master and slave PICs, respectively) are connected, so whenever IRQ 2 occurs, IRQ 9 also occurs (this can be changed, but most devices expect IRQ 2 to be reserved for this purpose, and therefore do not use it).
A device sends the PIC an interrupt, and the PIC tells the CPU which interrupt number (between 00h and FFh, or 0 and 255 decimal) is to be serviced. When the system first starts up, the IRQs 0-7 are set to interrupts 08h-0Fh. IRQs 8-F are set to interrupts 70h-77h. Therefore, if IRQ 6 is sent to the PIC by a device, the PIC would tell the CPU to service INT 0Eh, which presumably has code for interacting with whatever device sent the interrupt in the first place. Of course, there can be trouble when two or more devices share an IRQ; if you wonder how this works, check out [
<pre>
Line 34:
and the PIC sends the interrupt assigned to IRQ 3, which the CPU handles (using the IDT to look up the handler for that interrupt).
Alert readers will notice that the CPU has reserved interrupts 0-31, yet IRQs 0-7 are set to interrupts 08-0Fh. Now the reserved interrupts are called when, for example, a dreadful error has occurred that the OS must handle. Now when the computer first starts up, most errors of this type won't occur. However, when you enter protected mode (and every OS should use protected mode, real mode is obsolete), these errors may occur at any time, and the OS needs to be able to handle them. How's the OS going to tell the difference between INT 9, Exception: Coprocessor segment overrun, and INT 9: IRQ 1? Well, it can ask the device whether there is really an interrupt for that device. But this is slow, and hackish, and not all devices are able to do this type of thing. The best way to do it is to tell the PIC to map the IRQs to
See [
Line 42:
Every time the CPU is done with one machine instruction, it will check if the PIC's pin has notified an interrupt. If that's the case, it stores some state information on the stack (so that it can return to whatever it is doing currently, when the INT is done being serviced by the OS) and jumps to a location pointed to by the IDT. The OS takes over from there.
The current program can, however, prevent the CPU from being disturbed by interrupts by the mean of the
==From the OS's perspective:==
When an interrupt comes in, the IDT (which is setup by the OS in advance) is used to jump to code portion of the OS, which handles the interrupt (and therefore called the "interrupt handler" or "[Interrupt Service Routines|Interrupt Service Routine]"). Usually the code interacts with the device, then returns to whatever it was doing previously with an <tt>iret</tt> instruction (which tells the CPU to load the state information it saved, from the stack). Before the
<pre>
Line 71:
Step by step, now that you've grabbed the whole thing and know what's to be done:
* Make space for the interrupt descriptor table
* Tell the CPU where that space is (see [[
* Tell the PIC that you no longer want to use the BIOS defaults (see [
* Write a couple of ISR handlers (see [[Interrupt Service Routines]]) for both IRQs and exceptions
* Put the addresses of the ISR handlers in the appropriate descriptors
|