What is interrupt in assembly language?

Answer 1

An interrupt (for example, Intel-based opcode 0xCD) causes the CPU to pause its current execution, store the state of the registers on the stack, then process a defined subroutine. When this subroutine completes, the interrupt finishes, the registers are restored from the stack, and the previous execution state resumes. Interrupts come in two basic flavors: hardware and software.

A hardware interrupt occurs when a connected piece of hardware raises an IRQ signal. This mechanism tells the CPU that the hardware has information that needs to be processed. This is more efficient than polling for devices that have relatively few inputs or that have a latency that the CPU shouldn't wait for. Keyboards and mice are often interrupt-driven; the CPU only needs to know when something interesting has happened (a key was pressed or the mouse was moved, for example). Hard drives are also interrupt-driven; this allows the hard drive to locate the requested data and then return that data some CPU cycles later without the CPU having to request the status of the operation repeatedly.

In contrast, a software interrupt is usually triggered by software as a means of invoking operating system code in a reliable manner. For example, in MS-DOS, a developer would call INT 0x21 in order to invoke typical DOS commands, such as reading or writing a file, obtaining keyboard input, and other basic operations. Most older operating systems running on Intel-compatible processors use software interrupts to provide a way for the program to access system functions. Newer operating systems use new opcodes that circumvent the need for software interrupts, although most platforms still provide this mechanism for legacy software.

Answer 2

This is a terrible question to answer on so many levels. I will attempt to answer it without getting carried away.

A hardware interrupt is a signal produced by a device that informs the CPU that the device needs attention. The CPU then "interrupts" the current running software on the PC and executes code to attend to the interrupt and clear the message. The software then resumes processing.

On x86 based architectures, the interrupt signal is electronically multiplexed to allow for what feels like multiple interrupts with the CPU. This is accomplished using a separate chip, originally the i8259. When the interrupt fires, the system interrupt handler is triggered and then checks the status of the i8259 to identify the interrupt number which has been signaled and looks up a function to execute in a table in memory.

Software can also trigger interrupts similar to hardware and the x86 CPU has been designed to allow identifying a numerical interrupt value to reference the before mentioned interrupt table and cause an operating system function to be called.

On 32-bit CPUs, it has become uncommon to develop using interrupts with the exception of when calling into the operating system kernel. When an interrupt is generated, the context of the application running in ring 3 protected mode and the interrupt handler residing in ring 0 (a generally unprotected mode) is called. So for example, when a windows app wants to allocate more memory than it currently has available, the function VirtualAlloc is called which sets up a call structure to pass to the operating system. It the fires the interrupt and the system drops to ring 0, calls the interrupt handler which then forwards the call to the OS. The OS allocates the memory, stores the result in a structure and them returns to the interrupt handler which then returns to ring 3.