Support from OS
- Support for Asynchronous Events
- events from devices
- user input
- timer events
- Hardware Protection
- user mode vs. supervisor mode
- privileged instructions
- all I/Os
- Support for Address Spaces
- Timers can be set, and a interrupt occurs when the timer expires.
When an interrupt occurs, the CPU:
- saves state
- changes into supervisor mode
- branches to predefined location.
Return-from-interrupt (rti) automatically restores state. Interrupts/Exceptions can be invoked by asynchronous events (I/O devices, timers, various errors) or can be software-generated (system calls).
Example in 32-bit Linux:
- load system call number in register eax
- load arguments to system call in registers
ebx , exc , edx , esi , edi , ebp
- invoke software interrupt: int 0x80
- Returned values are stored in eax
Software interrupts are expensive! Compiler optimization not possible.
- Cost of context switch (saving/restoring registers)
- Caches are stale
- CPU pipelines
Why still interrupts or system call?
- Can load user program into memory without knowing exact address of system functions.
- Separation of address space, including stacks: user stack and kernel stack.
- Automatic change to supervisor mode.
- Can control access to kernel by masking interrupts.
Handling exceptions on x86
Interrupt descriptor table (IDT)
- Interrupt Vector Table x86-style:
- processor exceptions, hardware interrupts, software interrupts
- 256 entries: Each entry contains address of interrupt handler (interrupt service routine).
- The first 32 entries reserved for processor exceptions (division by zero, page fault, etc.)
- Hardware interrupts can be mapped to any of the other entries using the Programmable Interrupt Controller (e.g. 8259 PIC)
The exception handling procedure is as below.
There are 4 steps here,
- save states
- call dispatch function
- load states
- return from interrupt
This is my class notes while taking CSCE 611 at TAMU. Credit to the instructor Dr. Bettati.