Lecture Topics
• Role of system software
• System calls, exceptions, & interrupts
• Processor support for interrupts
MP1 Handin and Demo Schedule
• Code must be committed to master/main branch on GitLab by
– 9:59AM on 2/18 (11:59PM on 2/18 for ZJUI)
• Handin Demo
– Monday 2/22, Starts at 6 PM: All ZJUI Students and Last names from A to J
– Tuesday 2/23, Starts at 6 PM: Last names from K to Z
Role of System Software (1)
• System software serves three purposes – virtualization
– protection
– abstraction (particularly hiding asynchrony)
• virtualization:
– the illusion of multiple/practically unlimited resources
• protection:
– reduce/eliminate the chance of accidental and/or malicious destruction of data/results by another program
Role of System Software (2)
• abstraction:
– hide fundamentally asynchronous nature of processor/device interaction
– provide simpler and more powerful interfaces (integrated w/protection)
your code
someone else’s code
neither can cross protection boundary
buf
buf
buf
ETH
•
•
System Calls, Interrupts, and Exceptions (1)
recall that subroutines allow a programmer to encapsulate common operations
the operating system
– want to provide an interface including common operations
– BUT don’t want to re-link programs
– NOR rely on everyone having exactly the same OS version
CALL
1 4
5 CALL
6
2
73
System Calls, Interrupts, and Exceptions (2)
• solution
– add a level of indirection!
• with indirection
– to rewrite OS, just change the table – application code does not change
0
1
2
3
4
CALL #1
table of function pointers
called “handlers” or “handler procedures”
•
System Calls, Interrupts, and Exceptions (3)
in LC-3, we used the TRAP instruction; in x86, it’s the INT instruction:
INT 8-bit imm. # (PUSH EIP), EIP table[imm8]
– the RTL is actually a little more complicated, as you’ll see
later in course
– called a trap (after instruction, or trap door through protection boundary)
– also called a system call (for operating system)
System Calls, Interrupts, and Exceptions (4)
• vector tables/jump tables
– i.e., tables of function pointers
– convenient abstraction for many procedure-like activities
• Question:
– What happens if software does something wrong, e.g., • accesses a non-existent memory location?
• issues an illegal/undefined instruction? divides by 0?
• What do we do to handle problems?
– state machine that you design for processor may have don’t cares
– state machine that you build will do something (may be unknown) – so just let it run! (e.g., 6502 did so… and programmers used!)
System Calls, Interrupts, and Exceptions (5)
• a better solution: exceptions!
– processor maps each problem to a vector # – calls procedure in vector table by #
• Where else might we use vector tables?
• Consider processor interactions with devices – a disk access takes about 10 milliseconds
– new machines in lab: 10 ms = 32 million cycles
• should processor sit around asking, “Are my data here yet?”
System Calls, Interrupts, and Exceptions (6)
– analogous to posting a letter to a friend in Europe
– and checking your mailbox every minute for a reply
– instead, have your mail carrier ring your doorbell when it arrives – in a processor, we call that an interrupt
• How can we use a vector table for interrupts?
– each device has a vector #
– call corresponding procedure in vector table when device generates a request for service
• x86 ISA
– uses one table for all three kinds
– called the Interrupt Descriptor Table (IDT)
Processor Support for Interrupts (1)
• How does a processor support interrupts? • Logically…
INTR
N which one?
N=8 on x86 (and LC-3)
• How should we change a processor’s state machine to incorporate interrupts?
LC-3 state machine interrupt support
Z. Kalbarczyk ECE391
Processor Support for Interrupts (2)
INTR
NMI
8 which (uses data bus)
• x86 allows software to block interrupts with a status flag (in EFLAGS)
• normal interrupts occur only when the interrupt
enable flag (IF) is set
• some interrupts are too important
– e.g., memory errors, power warnings, etc.
– these are NOT maskable, and use a separate input to processor
– called non-maskable interrupts (NMI)
x86
Interrupt Descriptor Table
• as mentioned earlier
– x86 uses a single vector table
– the Interrupt Descriptor Table (IDT)
– hold vectors for interrupts, exceptions, and system calls
• note that this picture is partly OS-specific
– the exception vector numbers are specified by Intel – Why?
• A: generated directly by processor’s state machine
– programmable interrupt controller (PIC) will be discussed later;
• range of vectors generated is programmable, and is shown for Linux 2.4
– note that a single entry is used for all system calls in Linux
Interrupt Descriptor Table
Interrupts, System calls, and Exceptions
Characteristics of interrupts, system calls, and exceptions with respect to a program being executed
Type
Generated by
Asynchronous
Unexpected
Interrupts
external device
YES
YES
Exceptions
invalid opcode or operand
NO
YES
System calls
deliberate, via INT instruction
NO
NO
© Steven Lumetta, Zbigniew Kalbarczyk ECE391
Device I/O
• How does a processor communicate with devices?
• Two possibilities
– independent I/O — use special instructions and a separate I/O port address space
– memory-mapped I/O — use loads/stores
and dedicate part of the memory address space to I/O
• x86 originally used only independent I/O
– but when used in PC, needed a good interface to video memory – solution? put card on the bus, claim memory addresses!
– now uses both, although ports are somewhat deprecated
© Steven Lumetta, Zbigniew Kalbarczyk ECE391