Understanding Interrupts and Exceptions in Programming

Exceptions and interrupts pause a program in response to an unexpected event in hardware or software. Interrupts are asynchronous events, and exceptions are synchronous events. The difference between interrupts and exceptions also depends on the circumstances. For example, the definitions differ between x86 machines and ARM processors and between CISC and RISC processors.

This FAQ begins with an overview of the general definitions of interrupts and various types of exceptions. It then compares the differences in definitions in several computing environments and explains how interrupts are prioritized for handling.

Exceptions are sometimes called “traps” and can be triggered by an exception or error in a process when executing a function. Conditions like division by zero, a breakpoint, or invalid memory access occur synchronously with the execution of a program. They can result in an exception that changes the operation of the processor. Once the cause of the exception has been handled, the processor returns to its previous activity. Interrupts, on the other hand, are issued asynchronously and can arrive at any time. For example, the generation of a keystroke by a user initiates an interrupt.

Exceptions are a subset of software-driven interrupts, which can originate from software or hardware sources. When an exception occurs, the exception handler performs a specific function defined by the exception type. Similarly, an interrupt triggers a specific routine by the processor, such as processing keystrokes in a timely manner as they arrive, as seen in Table 1 below.

Table 1. At a basic level, exceptions (traps) are defined as synchronous events originating in software, while interrupts are asynchronous events caused by external hardware. (Table: Baeldung)

In an MCU, interrupts can indicate electronic or physical changes in a hardware device that need timely attention. Interrupts are used in real-time computing to support multitasking. Most MCUs are interrupt-driven devices. A specific bus control line in the MCU handles the reception of interrupts through an INT pin.

The INT pin connects with multiple external devices such as keyboards, network interconnect cards, USB interfaces, etc. An interrupt controller informs the processor which device issued the interrupt, enabling the processor to implement the necessary interrupt handler procedure. In some cases, an interrupt causes the CPU to begin executing code from an interrupt vector table with specific instructions. Interrupts can originate from hardware, software, or another processor, as seen in Figure 1. Another way to categorize interrupts is by the source:

Exceptions are triggered within the CPU
Interrupts triggered by external hardware devices
Interrupts triggered by software sources
Interprocessor interrupts are triggered by a different CPU in a multitasking or real-time computing environment

Figure 1. Interrupts can originate within external hardware, in the processor or another processor (in multi-core environments), or from software. (Image: Wikipedia)

Exceptions are sometimes divided into two categories based on how serious the condition is:

Aborts, which stop the code from executing until the condition has been handled. They’re typically caused by major problems such as hardware failures, divide-by-zero errors, and so on.
Traps, which also need to be handled, but don’t stop the code from executing. They are used for virtual memory management, program debugging, and similar functions.

Dealing with interrupts

There are generally three stages of exception or interrupt handling:

“Recognition” occurs when the processor identifies the source of the exception.
An exception or interrupt is ‘taken’ when the handler takes control of instruction execution, the context is saved, and the handler routine starts running in supervisor mode, sometimes called a privileged state.
Exception or interrupt ‘handling’ occurs in supervisor mode and continues until the processor resumes executing the program code.

Definitions differ

Interrupts can be classified as exceptions, traps, faults, and aborts, but it’s not that simple. It depends on the context and the specific platform being considered. In various environments, “trap” can refer to any interrupt, software interrupt, or synchronous software interrupt. In addition, the term can apply only to interrupts resulting from instructions with “trap” in their name or to a breakpoint that initiates a monitor program or debugger. Interrupts have different classifications in x86 and ARM environments.

In an x86 environment, there are hardware interrupts and software exceptions, with three different types: faults, traps, and aborts. Interrupts in an x86 environment are triggered asynchronously by any I/O device. When the program is ‘interrupted,’ it can be restarted without losing functionality. A “fault” also results in a restartable condition but is a synchronous event related to software execution. A “trap” is like a fault but with a different return address. In a trap, the return address points to the instruction to be executed after the trapping instruction, while in a fault, the return address points to the faulting instruction. Traps are often used for system calls. An “abort” results from serious errors and often does not allow the program to be restarted.

In an ARM architecture, the term ‘exception’ can refer to all types of interrupts. In this case, exceptions are classified as hardware interrupts, resets, exception-generating instructions, and aborts. Aborts in an ARM MCU include data aborts (failed data accesses) or instruction aborts (failed instruction fetches), also called prefetch aborts. While ‘exceptions’ in an x86 environment are synchronous events, they can be synchronous or asynchronous in an ARM environment. In addition, ARM “exceptions” can be precise or imprecise (as defined in the next section).

RISC differences

Compared with CISC architectures, RISC MCUs take a different approach to interrupts or exception handling. These differences can initially be more challenging for designers than the differences between x86 and ARM architectures. RISC machines recognize four types of exceptions:

Asynchronous precise
Asynchronous imprecise
Synchronous precise
Synchronous imprecise

As with the other cases, asynchronous exceptions can occur at any time, while synchronous exceptions are synchronized with the instruction flow. The introduction of the concepts of precise and imprecise exceptions is an important distinction:

A precise exception has a precisely defined cause and is usually recoverable.
An imprecise exception is unrecoverable, meaning the processor can’t continue to perform the program, which usually results in a catastrophic failure.

Synchronous precise are the result of instruction exceptions. Depending on the specific cause, the address of the faulting instruction or the next instruction is retained for use after the exception has been handled. The exception handler determines if the faulting instruction is partially or fully completed and determines how it should be handled.

Synchronous imprecise exceptions are used in RISC-V processors but are not fully supported in PowerPC devices. Synchronous imprecise exception handling is defined for specific floating-point exceptions in the PowerPC architecture. The general concept of synchronous imprecise exceptions may be more fully implemented in the future.

Asynchronous precise, sometimes called “maskable”, can be caused by external interrupts, decrementer faults, system management interrupts, thermal management interrupts, etc. During an asynchronous precise exception, the instructions are processed before the exception is completed and handled. The next instruction is stored and acted upon when the exception is cleared. Since these exceptions result from external devices, several exceptions can occur simultaneously or in rapid succession before any given exception has been handled. Some exceptions can be missed if there is insufficient storage in the exception handler. One way to address this potential problem is to include some form of handshaking between the exception handler and the external devices to ensure that all exceptions have been received and acknowledged.

Asynchronous imprecise, sometimes called “nonmaskable”, exceptions include only system resets and machine checks. When a system reset occurs, the CPU stops, all internal memories and registers are reset, then the processor restarts. A machine check exception is a computer hardware error that occurs when the CPU detects a hardware error in the processor itself, the memory, the I/O devices, or the system bus. In the case of PowerPC devices, software errors, such as some invalid memory accesses, can also cause a machine check exception. Most machine-check exceptions stop the operating system and require a restart before the operation can resume.

Recognizing RISC exceptions

Exception recognition can be especially challenging when instructions are executed out of program order. For example, PowerPC handles synchronous exceptions in strict program order, even though instructions further on in the program flow may have generated an additional exception. The first exception is handled as if the preceding instructions have all been executed and the following instructions have not.

Of course, multiple exceptions can occur simultaneously. In that case, the exceptions are handled based on specific priorities, as shown in Table 2. Asynchronous imprecise exceptions have the top priority, and within this category, system reset exceptions are a higher priority than machine check exceptions. Next are synchronous precise exceptions handled in program order, followed by synchronous imprecise. Asynchronous precise exceptions have the lowest priorities, with external interrupts given a higher priority than internal interrupts such as decrementer and system management interrupts.

Table 2. RISC devices have strict exception-handling priorities when multiple exceptions occur simultaneously. (Table: BrainKart)

Summary

At a basic level, exceptions are classified as a subset of interrupts. More specifically, exceptions are synchronous events originating in software, while interrupts are asynchronous events caused by external hardware. The definitions of interrupts and exceptions vary between computing architectures, such as x86, ARM, and RISC. Various causes of exceptions and interrupts have different levels of severity in terms of disrupting system operation. As a result, strict priorities are implemented for dealing with specific conditions.