Interrupt Types: Hardware, Software, Vectored/Non‑Vectored, and Exceptions

Interrupts are events that temporarily divert a CPU from its current execution path to run an interrupt/exception handler. In most architectures, the distinction among interrupt types depends on source (external vs internal), timing (asynchronous vs synchronous), and dispatch mechanism (vectored vs non-vectored).

A useful taxonomy for your topic:

• hardware interrupt: typically asynchronous signals from devices (e.g., timers, I/O controllers).
• software interrupt: generated intentionally by executing an instruction or via OS services.
• vectored interrupt: typically uses a vector/cause to select the handler directly.
• non-vectored interrupt: a single entry point is invoked, then software identifies the device/cause.
• exception: raised by the CPU during instruction execution (e.g., fault/abort conditions).

Mermaid overview of the relationships:

Note: Exact naming varies by ISA/OS (e.g., “exception vs interrupt” conventions on ARM vs x86), but the conceptual split above is consistent.

This section gives you a “compare-and-describe” framework. Use it to classify any interrupt-like event you encounter in an ISA manual, OS kernel documentation, or course notes.

Key terms to anchor the taxonomy

• interrupt line
• interrupt handler
• interrupt vector
• exception cause

(Definitions above are used throughout the remainder of the course content.)

1) Hardware Interrupts

hardware interrupts originate outside the CPU core—usually from peripherals, timers, DMA completion, GPIO events, network controllers, etc. They are commonly:

• Asynchronous relative to the executing program (can occur between instructions).
• Signal-based (e.g., an interrupt request line asserted by a device).
• Dispatchable via vectors (if the architecture supports vectored delivery) or via a shared entry point (non-vectored).

A simple conceptual pipeline:

Common OS responsibilities typically include:

• acknowledging the interrupt at the controller/device,
• determining which device caused it (especially for non-vectored cases),
• invoking the appropriate driver-level handler.

2) Software Interrupts

software interrupts are triggered intentionally by executing an instruction (or by OS mechanism) to transfer control into a privileged handler.

Typical reasons include:

• performing a system call (e.g., a “trap” into the OS),
• invoking a specific service routine (depending on ISA),
• intentionally changing privilege level or switching execution context.

Software interrupts tend to be:

• Controlled by code,
• often treated as synchronous from the perspective of the executing instruction stream (because the software instruction explicitly causes the trap).

In many ISAs, a “software interrupt” behaves like a “trap/exception class” internally—i.e., the CPU recognizes a specific instruction encoding and vectors to the corresponding handler.

3) Exceptions (CPU-Detected, Usually Synchronous)

exceptions are raised by the CPU while executing instructions due to abnormal or exceptional conditions such as:

• invalid opcode / illegal instruction,
• divide error / arithmetic fault,
• page fault / access violation,
• overflow or alignment faults (depending on ISA settings).

Conceptually, exceptions are:

• Synchronous: tied to the instruction currently being executed.
• categorized by cause (exception number/type).
• dispatched to an appropriate handler via the exception mechanism (often vectored by an exception code/cause).

A helpful way to distinguish:

• If the program caused it via a deliberate instruction, it’s often treated as a software interrupt/trap.
• If the CPU detects a fault while executing the program, it’s an exception.

4) Vectored Interrupts vs Non‑Vectored Interrupts

The “vectored/non‑vectored” distinction describes how the CPU finds the correct handler when an interrupt occurs.

4.1 Vectored Interrupts

A vectored interrupt includes (directly or indirectly) enough information to select the handler without extensive software probing.

Typical characteristics:

• The interrupt controller supplies a vector (or cause ID).
• The CPU can jump to the correct handler entry directly.
• Faster dispatch; less “interrupt source identification” work in the generic entry point.

4.2 Non‑Vectored Interrupts

A non-vectored interrupt does not provide a unique handler address/cause at the time of entry. Common behavior:

• CPU enters a single common handler entry point.
• software reads status registers / pending bits to identify the true source,
• then software dispatches to the appropriate device handler.

Trade-offs:

• Simplifies hardware wiring (no per-source vector delivery).
• Typically increases latency due to extra software identification steps.