Linked by Hadrien Grasland on Sun 27th Feb 2011 12:06 UTC
Hardware, Embedded Systems This is a situation where I need the help of you OSnews readers who are experienced with low-level development on ARM, SPARC, PowerPC, MIPS, and other hardware architectures we have on computers nowadays. The issue is that I'm currently designing the part of my hobby kernel which takes care of interrupts. Although I mostly work on x86 at the moment, I'd like to keep this code portable to other hardware architectures in the future. To do that, I have to know how interrupt handling works on as much HW architectures as possible.
Permalink for comment 464282
To read all comments associated with this story, please click here.
Comment by Morin
by Morin on Mon 28th Feb 2011 11:41 UTC
Member since:

> The interrupt handling model which I'm currently
> checking for portability is:

I can tell you where your model is not universally portable. I cannot name specific architectures that use different models, because my experience comes from FPGA based circuits where you would change even the hardware parts as you see fit.

> Hardware emits an interrupt signal

The signal can be edge-triggered or level-triggered. This is usually of little concern for an OS developer, because either way the interrupt is captured such that an interrupt that occurs while the CPU cannot handle it immediately isn't lost.

> On its way, the signal optionally encounters one or
> more PICs which either stop it or direct it to one
> of the CPU's interrupt pins (this means that PIC
> drivers are necessary on architectures which have
> one, but that they may be written separately)

External modules such as the PICs from PC mainboards are indeed optional, but if present, might perform arbitary functions: masking out unwanted interrupts; re-mamping to different IRQ numbers; even masking two interrupts to the same number. Such modules would also be specialized to the hardware interrupt protocol (which again is of little interest to the OS developer).

> The CPU reacts to the signal on its interrupt pin by fetching a "vector", noticeable containing the memory address of the interrupt handler associated to that pin, doing some arch-specific tricks, and executing code at said address

Some CPUs use an address table as you describe. Some others use a fixed address for all interrupts and let the software determine what caused the interrupt. Others use fixed addresses that depend on the IRQ number. Others use a few fixed addresses where most interrupts share one table entry and a few performance critical ones use another.

CPUs may also allow to mask interrupts internally at different scopes, e.g. globally and per IRQ number. CPU differ in the way that interrupts are automatically masked when an interrupt occurs: some mask all interrupts on interrupt entry, others define a priority and only mask lower-or-equal-priority interrupts.

x86 specifically defines a lengthy procedure that set up a process environment (not only an entry address) entirely in hardware before software handling even begins; this is called "interrupt gate" IIRC. Remember that x86 defines a whole OS in microcode, although that is rarely used anymore.

Reply Score: 3