operating systems - How do hardware interrupts work compared to software interrupts?
2014-04
artistoex
To give you an impression of the level of detail I'm interested, one example. I know a system call ultimately leads to a trap which lets the processor store registers, switch to supervisor mode and perform an indirect jump. But that's only a special case (or is it?).
So what exactly happens at the hardware level when hardware or software interrupts occur, in general?
What are the differences and commonalities? How exactly do hardware and operating system cooperate to get interrupts work the way they do?
soandos
A hardware interrupt takes place on a hardware level. These can be things like traps and halts, where the processor itself saves its state and waits for input or executes something else that was not necessarily part of the original program (i.e. if you divide by zero, your processor has to do something that it was not intending to do during the normal execution of the program).
Perhaps more importantly, a hardware interrupt allows a processor not to waste time in what are called polling loops. Imagine if you had to see if the user was pressing a key. There are two ways of doing that. The first is by checking very often and seeing if the key is pressed. While this will work, it is wasteful, as the vast majority of the time the check comes back negative. Interrupts allows the key press itself to change the state of the program so that it gets "notified" when a key is pressed. The second way is clearly more efficient in many cases.
A software interrupt usually means a context switch, and it done by the operating system. In some cases it means nothing more than the OS swapping which program is executing at the moment (if your computer is running 50 processes, unless you have 50 cores/threads the fact that programs simultaneous program execution is an illusion) so something similiar to the above example with the keyboard, where it is waiting for some event to occur (see more about event based programming here (from Wikipedia))
It is important to note that while in many cases interrupt based programming is a good idea, in application where there are many interrupt based programming is a good idea, if it occurs too frequently, it may be less efficient, and perhaps even crash the system.
Questioner
How can a program running on a CPU (mostly OS) access other PC hardware? Such as Graphic card, HDD and so?
From what I read, in DOS, this was done using BIOS calls, specifically the INT instruction. But, the INT instruction should only jump to the certain space in RAM. So how can some program stored in RAM access other computer hardware, when the CPU can only access RAM, and receive interrupts?
Does Windows use INT instructions as well, or is there a new way to communicate with the hardware?
mctylr
[H]ow can program runnig on CPU (mostly OS) acess other PC hardware? Such as Graphic card, HDD and so?
The complete answer to this question is complex and difficult to answer in general. So I'm going to try to answer it in general, and hopefully give you some pointers for finding additional information for further learning. I hope this is useful.
For 32/64-bit protected modes as used by MS Windows 95 and newer, or Linux on an x86 (IA-32) processor, software interrupts (such as the INT opcode for x86) go to the appropriate Interrupt vector table (or dispatch table) which may direct the CPU where in the OS the process should jump to the interrupt handler (or Interrupt Service Routine, ISR) for handling the request.
In x86 real-mode, like MS-DOS these may be handled by the BIOS that provides low-level specific implementation details for that particular system / chipset / motherboard.
[H]ow can some program stored in RAM acess other computer HW, when CPU can acess only RAM, and reeive interrupts?
So you don't want the usual hand-wavy answer? I'll try to answer this, but I am not a computer engineer or expert of computer architecture.
There are various mechanisms including
- memory mapped or port mapped I/O
- Direct Memory Access (DMA)
- IO Processors (I/O "channels")
- Peripheral Processing Units
(Src: CS 473 - IO, New Mexico State University, pfeiffer, 2006)
The simplest is memory mapped I/O where an memory address might be mapped to the registers of a hardware device (e.g. serial UART) and the CPU and write and/or read certain memory addresses to access the hardware directly. This is fast, and simple, but reduces the memory address range of what can be used as RAM.
The others are more advanced techniques developed to allow modern CPUs and more advanced Operating Systems access hardware in a controlled fashion.
In the OS itself, these are normally referred to as device drivers, as they include specific details about the hardware devices they support.
And, does windows use int instructions as well, or is there any new way to communicate with HW?
Yes, and yes, but I think I've explained that.
CesarB
There are several ways software running on the CPU on a PC can communicate with the rest of the hardware.
The simplest to understand are I/O ports. The software uses the OUT instruction to write 8, 16, or 32 bits at a time to a I/O port. In the same way, the software uses the IN instruction to read from a I/O port. The I/O ports live in a separate 16-bit address space, unrelated to the addresses space used by the main memory. Each piece of hardware which uses I/O ports has a range of I/O addresses; writing to and reading from each of these addresses has a different effect (and often reading from and writing to the same address has different effects too).
Another way is memory-mapped I/O, where part of the memory address space is mapped to a piece of hardware. Instead of going to the main memory, the reads and writes from and to that region of memory go to the corresponding hardware. What they mean depends on the hardware and on the region (it is not uncommon to have more than one memory-mapped I/O region in the same piece of hardware); reading and writing to it could have a special effect (as is common with I/O ports) or it could simply read and write directly to memory on the hardware (for instance, a video card's frame buffer).
On the other direction (the rest of the hardware talking to the software running on the CPU), there are also several ways. The simplest one would be to wait for the software to ask (either via an I/O port or memory-mapped I/O); used alone, this can be very inefficient.
Another way is for the hardware to write directly to the main memory. This is very efficient for transfering large amounts of data, and can be used in the other direction too (to read from the main memory). However, the software still has to know when the transfer is finished.
The last way is interrupts. The CPU receives an interrupt request, together with the interrupt number. The CPU interrupts (thus the name) what it was doing, and switches to another part of the code (which part depends on the interrupt number). Usually each hardware corresponds to a single interrupt number, but interrupt numbers are often shared by several interrupt sources. There are also special kinds of interrupt which do not have a number; for instance, the NMI.
For a practical example, let's take a simple network interface card. This network card has a set of registers, which can be acessed either via I/O ports or memory-mapped I/O. It can also read from and write to the main memory, and has an interrupt pin.
To send a packet to the network, the network card driver first writes the full packet to the memory, at an address aligned to a multiple of 4 bytes. It then writes to a couple of registers on the network interface card, telling it the memory address, the packet size, and some other information. The network card then reads the packet from the memory, sends it to the network, and signals the interrupt. The interrupt controller (a separate piece of hardware) sends the interrupt request to the CPU and tells it the interrupt number. In the interrupt handler, the driver reads a register from the card which tells it the interrupt was about a packet being sent, reads another register to find out which packet was sent, and knows it can now reuse the memory where it had written the packet.
To receive packets from the network, the network card driver allocates a block of memory to be used as storage for the packets, and writes several registers on the card telling it the memory address of the block of memory, its size, and some other information. When a packet is received from the network, the network card writes it to that block of memory, together with the packet's size and some other information. It updates some registers which tell both it and the driver how much free space is there in that block of memory, where the free space begins, and where the used space begins (the buffer is circular, so after getting to the end it rolls over to the beginning). Finally, it signals its interrupt. The driver will read the registers and the memory to obtain the packet(s), and will update the registers to tell the card that space is now free again.
There are other things the card can tell the driver by writing its registers and signalling an interrupt; for instance, that the network cable was unplugged, that there was a transmission error, and so on.
Satanicpuppy soandos
That would be what hardware drivers are for. In addition, windows now uses a HAL (Hardware Abstraction Layer) in place of DOS.