CPSC 213 Exceptions, Logical Control Flow, Signal Terminology, - PowerPoint PPT Presentation

Reading ‣ Text CPSC 213 •Exceptions, Logical Control Flow, Signal Terminology, Sending Signals, Receiving Signals •8.1, 8.2.1, 8.5.1-8.5.3 Introduction to Computer Systems Unit 2a I/O Devices, Interrupts and DMA 1 2 Looking Beyond the CPU and Memory Talking to an I/O Controller read 0x1000 addresses Memory Bus 0x0 - 0x7 fgfgfg f CPU Memory read 0x80000000 I/O Bus The I/O Controllers Processors 0x80000000 0x80000400 - ... - 0x800000 fg 0x800004 fg I/O Devices ‣ Programmed I/O (PIO) • CPU transfers a word at a time between CPU and I/O controller • typically use standard load/store instructions, but to I/O-mapped memory ‣ Memory Bus ‣ I/O Controller ‣ I/O-Mapped Memory • data/control path connecting CPU, • a processor running software • memory addresses beyond the end of main memory Main Memory, and I/O Bus (firmware) • used to name I/O controllers (usually configured at boot time) ‣ I/O Bus • connects I/O Device to I/O Bus • loads and stores are translated into I/O-bus messages to controller • e.g. SCSI, SATA, Ethernet, ... ‣ Example • data/control path connecting Memory ‣ I/O Device Bus and I/O Controllers • to read/write to controller at address 0x80000000 • e.g. PCI • I/O mechanism that generates or ld $0x80000000, r0 consumes data st r1 (r0) # write the value of r1 to the device ld (r0), r1 # read a word from device into r1 • e.g. disk, radio, keyboard, mouse, ... 3 4

Limitations of PIO Key Observation ‣ Reading or writing large amounts of data slows CPU •requires CPU to transfer one word at a time •controller/device is (often) much slower than CPU The •and so, CPU runs at controller/device speed, mostly waiting for controller Processors ‣ IO Controller can not initiate communication •sometimes the CPU asks for for data ‣ CPU and I/O Controller are independent processors •but, sometimes controller receives data for the CPU, without CPU asking - e.g., mouse click or network packet reception (everything is like this really as we will see) •they should be permitted to work in parallel •how does controller notify CPU that it has data the CPU should want? •either should be able to initiate data transfer to/from memory ‣ One not-so-good idea •either should be able to signal the other to get the other’s attention •what is it? ___________________________________________________ •what are drawbacks? _________________________________________ •when is it okay? ______________________________________________ 5 6 Autonomous Controller Operation Adding Interrupts to Simple CPU ‣ New special-purpose CPU registers • isDeviceInterrupting set by I/O Controller to signal interrupt PIO: data transfer • interruptControllerID set by I/O Controller to identify interrupting device DMA: CPU <-> Controller initiated by CPU data transfer • interruptVectorBase interrupt-handler jump table, initialized at boot time Controller <-> Memory initiated by Controller Interrupt: ‣ Modified fetch-execute cycle control transfer controller -> CPU while (true) { ‣ Direct Memory Access (DMA) if (isDeviceInterrupting) { m[r[5]-4] ← r[6]; • controller can send/read data from/to any main memory address r[5] ← r[5]-4; • the CPU is oblivious to these transfers r[6] ← pc; pc ← interruptVectorBase [interruptControllerID]; • DMA addresses and sizes are programmed by CPU using PIO } ‣ CPU Interrupts fetch (); execute (); • controller can signal the CPU } • CPU checks for interrupts on every cycle (it's like a really fast, clock-speed poll) • CPU jumps to controller’s Interrupt Service Routine if it is interrupting 7 8

Sketching Interrupt Control Flow Big Ideas: Second Half Interrupt Vector ‣ Memory hierarchy Current Program ISR - Controller #0 ... ... •progression from small/fast to large/slow ... ... ... ... - registers (same speed as ALU instruction execution, roughly: 1 ns clock tick) ... iret ... - memory (over 100x slower: 100ns) ... ISR - Controller #1 ... - disk (over 1,000,000x slower: 10 millisec) ... ... - network (even worse: 200+ millisec RT to other side of world just from speed of light in fiber) ... ... ... ... •implications ... iret ... - don’t make ALU wait for memory ... ISR - Controller #2 ... • ALU input only from registers, not memory ... ... - don’t make CPU wait for disk ... ... • interrupts, threads, asynchrony ... iret ‣ Clean abstraction for programmer •ignore asynchronous reality via threads and virtual memory (mostly) 1. Controller #0 Interrupts ISR - Controller #3 2. CPU jumps to its ISR ... •explicit synchronization as needed 3. ISR returns to program ... ... iret 9 10 Adding I/O to Simple Machine I/O-Mapped Memory read 0x1000 addresses CPU Memory ‣ Beyond CPU/memory 0x00000000- read 0x7fffffff 0x80000000 Memory CPU •CPU: ALU and registers addresses addresses 0x80000000 0x80000400- 0x800004ff -0x800000ff addresses addresses addresses ‣ I/O devices have small processors: I/O controllers 0x80000100- 0x80000200- 0x80000300- 0x800001ff 0x800002ff 0x800003ff ‣ I/O-Mapped Memory •processing power available outside CPU • use familiar syntax for load/store for both memory and I/O Memory Bus • memory addresses beyond the end of main memory handled by I/O controllers CPU Memory - mapping configured at boot time I/O Bus • loads and stores are translated into I/O-bus messages to controller ‣ Example The I/O Controllers Processors • to read/write to controller at address 0x80000000 ld $0x80000000, r0 I/O Devices st r1 (r0) # write the value of r1 to the device ld (r0), r1 # read a word from device into r1 11 12

Programmed IO (PIO) Direct Memory Access (DMA) CPU Memory PIO: 1: PIO data transfer: data transfer CPU sends requests to 2: DMA CPU -> Controller controller and waits initiated by CPU data transfer until data is ready Controller <-> Memory 3: Interrupt initiated by Controller control transfer Controller -> CPU initiated by Controller ‣ CPU requests one word at a time and waits for I/O controller ‣ I/O controller transfers data to/from main memory independently of CPU • CPU must wait until data is available - but I/O devices may be much slower than CPU (disks millions of times slower) • process initiated by CPU using PIO • large transfers slow since must be done one word at a time - send request to controller with addresses and sizes • CPU must check back with I/O controller (for instance by polling) • data transferred to memory without CPU involvement - poll too often means high overhead • controller signals CPU with interrupt when transfer complete - poll too seldom means high latency ‣ can transfer large amounts of data with one request • no way for I/O controller to initiate communication • not limited to one word at a time - for some devices CPU has no idea when to poll (network traffic, mouse click) 13 14 Reading from Disk (a Timeline) CPU I/O Controller 1. PIO to request read 2. PIO Received, start read ... ... wait for read to complete Programming with I/O do other things ... ... 3. Read completes 4. Transfer data to memory (DMA) 5. Interrupt CPU 6. Interrupt Received Call readComplete 15 16