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, but 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 for interrupts, and various types of exceptions, then compares the differences in definitions in several computing environments and 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, while interrupts 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 (Table 1).
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 interconnects 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 (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.
Exceptions are sometimes divided into two categories based on how serious the condition is:
Aborts stop the code from executing until the condition has been handled and are caused by major problems such as hardware failures, divide-by-zero errors, and so on.
Traps need to be handled but don’t stop the code from executing and 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’ takes place in supervisor mode and continues until the processor resumes executing the program code.
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 with no loss of 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 be used to 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).
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, and imprecise
- Synchronous precise, and 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 and means that the processor can’t continue to perform the program, and 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 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, and so on. During an asynchronous precise exception, the instructions being processed before the exception are completed before the exception is 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 an additional exception may have been generated by instructions further on in the program flow. 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 at the same time. In that case, the exceptions are handled based on specific priorities (Table 2). Asynchronous imprecise exceptions have the top priority, and within this category, system reset exceptions have 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.
At a basic level, exceptions are classified as a subset of interrupts. More specifically, exceptions are synchronous events originating in software, while interrupts are defined as asynchronous events caused by external hardware. And 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.
RISC exceptions, BrainKart
What Is the Difference Between Trap and Interrupt?, Baeldung