I want to understand how HW IRQ does work on a physical layer. I ask my question considering a specific example. As known after a packet coming to a network adapter a hardware interrupt is signalling. Wiki says that

an interrupt is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention.

I know that OS will be invoke a corresponding interrupt handler when the interrupt's type will be detected. But I don't understand how does CPU detect and distinguish incoming interrupts. Now I ask my questions:

First, why CPU does know that the interrupt is coming from network adapter, but not from other devices?

Second, Where does interrupt handlers registered in CPU? Is there exist a specific CPU's area which contains handler's addresses registered by OS?

  • \$\begingroup\$ Because either there is an interrupt dedicated to that device, the device notifies the CPU that it is the device invoking the interrupt, or the devices are polled to determine which one invoked the interrupt. In memory. \$\endgroup\$ Commented Dec 29, 2013 at 4:32
  • \$\begingroup\$ @IgnacioVazquez-Abrams Thanks for your answer! Can you get an example of the case when the device notifies the CPU that it is the device invoking the interrupt. I'm interested who this notifies is occuring in more detail. \$\endgroup\$ Commented Dec 29, 2013 at 5:27
  • \$\begingroup\$ It's all explained in gory detail in the datasheet for the CPU. \$\endgroup\$ Commented Dec 29, 2013 at 5:28

2 Answers 2


The details depend entirely on the CPU, so you're best to pick your favorite CPU and study it in detail. For more general knowledge, there are books on computer architectures, like those by William Stallings.

In one of the simplest, traditional designs, the CPU simply does not "know" at all which device interrupted it. The CPU has a single interrupt line. If there are multiple devices, they are all tied to that single line: for instance, with a big OR gate. When the CPU handles the interrupt, the top level of the interrupt handling routine has to interrogate all of the devices by peeking at their respective status registers, to determine which one, or which ones, require service. When they are properly dealt with, they de-assert the interrupt signal. Blocking specific interrupts can be implemented by making the external circuit sophisticated so that it can be programmed to selectively ignore some of its inputs.

This design can be improved upon in a myriad ways. For instance, there can be protocols whereby an interrupting device has to invoke a special bus cycle, and place its ID (8 bits or whatever) on the data bus, such that the CPU picks it up. The ID can then be used to index into an interrupt vector to dispatch an appropriate interrupt.

A processor doesn't even have to have interrupt pins; in one possible design, an interrupt is simulated when a device makes a write to some special memory location. Effectively, the address and data pins of the CPU serve as the interrupt inputs. See Message Signaled Interrupts.


In the original 8080, interrupts worked by having a pin which requested an interrupt along with an internal latch in the CPU to indicate whether interrupts were enabled. At some point during the execution of each instruction, the CPU would latch the "and" of (pin_asserted and interrupt_enabled). During the first cycle of the following instruction, the logic which drove the memory-access wires to perform a code fetch would cause them to be driven slightly differently when an interrupt was detected, and the "interrupt-enable" latch would turn itself off when that interrupt cycle was generated. External hardware would then typically notice the special pattern on the memory-access wires, and rather than outputting the contents of a memory address, would instead typically output a bit pattern corresponding to one of eight "RST" instructions [RST00 through RST38]. An RST38 instruction was equivalent to "JSR 0038h" (other RST instructions used addresses at multiples of eight from 0000h to 0030h), so the interrupt could cause execution to transfer to a particular address while recording the old location of the program counter. I'm not sure what the processor would have done if some other opcode had been put on the bus instead, esp. if it was the first byte of a multi-byte instruction]

Later processors generally operate on something of a similar principle, except that rather than relying upon an external device to generate an instruction they do so internally; since there will be a latch that says that the "instruction" is being serviced because of an interrupt, the behavior of that instruction need not match that of any which could be executed "normally". For example, while I don't know the internal details the circuitry for the Z80, its behavior when using vectored interrupts is a bit like a weird version of the CALL instruction: save the program counter to the stack, fetch a byte with a special pattern of special control pins asserted, load that byte into the LSB of the program counter and copy the I register to the MSB, and pretend that one has just fetched a JP (jump) opcode.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.