1. Microprocessor Programming and Application Input/Output

2. Input/Output Problems zWide variety of peripherals yDelivering different amounts of data yAt different speeds yIn different formats zAll slower than CPU and RAM zNeed I/O modules

3. Input/Output Module zInterface to CPU and Memory zInterface to one or more peripherals

4. External Devices zHuman readable yScreen, printer, keyboard zMachine readable yMonitoring and control zCommunication yModem yNetwork Interface Card (NIC)

5. I/O Module Function zControl & Timing zCPU Communication zDevice Communication zData Buffering zError Detection

6. I/O Steps zCPU checks I/O module device status zI/O module returns status zIf ready, CPU requests data transfer zI/O module gets data from device zI/O module transfers data to CPU zVariations for output, DMA, etc.

7. I/O Module Diagram (c.f. Memory) Data Register Status/Control Register External Device Interface Logic External Device Interface Logic Input Output Logic Data Lines Address Lines Data Lines Data Status Control Data Status Control Systems Bus Interface External Device Interface

8. I/O Module Decisions zHide or reveal device properties to CPU zSupport multiple or single device zControl device functions or leave for CPU zAlso O/S decisions ye.g. Unix treats everything it can as a file !

9. Input Output Techniques zProgrammed zInterrupt driven zDirect Memory Access (DMA)

10. Programmed I/O (a.k.a. polling, busy wait) zCPU has direct control over I/O ySensing status yRead/write commands yTransferring data zCPU waits for I/O module to complete operation (busy waiting, that is, CPU does nothing really) zWastes CPU time

11. Programmed I/O - detail 1.CPU requests I/O operation 2.I/O module performs operation 3.I/O module sets status bits 4.CPU checks status bits periodically 5.I/O module does not inform CPU directly 6.I/O module does not interrupt CPU 7.CPU may wait or come back later

12. Programmed I/O - detail  i = num_of_words_to_send; while ( i != 0) { repeat status = read (status_reg); until (status == 1); /* busy waiting */ i = i - 1; send (word[i]); }

13. Solutions zWe can employ DMA (direct memory access)  DMA controller performs faster I/O operations (synchronous) upon a request from CPU  However, what if the I/O wants to initiate I/O instead of the CPU (e.g. events, exception, traps...) ?  W e already learned that polling is wasteful (e.g. periodically checking the devices to see if they want to send data to the CPU) yPolling will not even work properly if the events must be processed right away (e.g. can not wait until the CPU checks what the device wants to do)  Allow I/O devices to issue desire to I/O ! (interrupts)

14. I/O Commands (1) zCPU issues address yIdentifies module (& device if >1 per module) zCPU issues command yControl - telling module what to do xe.g. spin up disk yTest - check status xe.g. power? Error? yRead/Write xModule transfers data via buffer from/to device

15. I/O Commands (2) zSpecial Instructions (now rare) y Input_ch R1; like get character y print_ch y …

16. Addressing I/O Devices zUnder programmed I/O data transfer is very like memory access (CPU viewpoint) zEach device given unique identifier zCPU commands contain identifier (address)

17. I/O Mapping zMemory mapped I/O yDevices and memory share an address space yI/O looks just like memory read/write yNo special commands for I/O xLarge selection of memory access commands available zIsolated I/O ySeparate address spaces yNeed I/O or memory select lines ySpecial commands for I/O xLimited set

18. Interrupt Driven I/O zOvercomes CPU waiting zNo repeated CPU checking of device zI/O module interrupts when ready zA way of I/O devices to alert the CPU by activating one of the control lines (Interrupt Request) of the CPU  Then, CPU "services" the interrupt and returns to its normal processing state. CPU does not poll on anything because the devices can raise interrupt any time they want (Asynchronous)  similar to procedure call ! (think of the exam problem)

20. Interrupt Driven I/O Basic Operation 1.CPU issues read command 2.I/O module gets data from peripheral whilst CPU does other work 3.I/O module interrupts CPU 4.CPU requests data 5.I/O module transfers data  a bit more efficient also (aside from the advantage of allowing I/O device to request I/O operations)

21. Non-DMA interrupt driven I/O with interrupt where the CPU computes something to be printed out continuously 1.CPU computes few lines of output 2.PRINT sends few lines of text for output 3.CPU continues to compute 4.PRINT ready interrupts and CPU sends few more lines for output 5.CPU continues to compute

22. CPU Viewpoint zIssue read command zDo other work zCheck for interrupt at end of each instruction cycle yAdd this to fetch-decode-execute-store cycle)  fetch – decode – execute – store – check interrupt (fast enough) zIf interrupted:- ySave context (registers) yProcess interrupt xFetch data & store

23. Interrupt Service Routine: (similar to subroutine or procedure in terms of what is internally done) 1.load PC with address of interrupt service routine 2.save CPU state and etc. 3.execute service routine 4.return to the previous point and restore CPU state (the CPU may (semi) automatically save parts of the CPU state) Note: interrupt routines and CPU program designers are in many cases different, therefore, to be safe, all registers are saved when saving state in response to interrupts... (i.e. do not know which registers are affected)

24. Issues zHow do you identify the module issuing the interrupt? zHow do you deal with multiple/simultaneous interrupts? yi.e. an interrupt handler being interrupted

25. Arrival of interrupt  It can be any time, but there are cases that the CPU does not want to or can not handle the interrupt (when ?)  We need the capability to "enable" or "disable" incoming interrupts...  Interrupt Masking: placing a user programmable interrupt mask register on interrupt request lines. The interrupt request line is ANDed with contents of mask register...  More generally, we need the capability to selectively "enable" or "disable" certain (not just all) interrupts...  e.g. PRINT should interrupt CPU when CPU is ready only, so the CPU will disable the interrupt until it is ready to output something...  Incoming interrupts may be served based on priority or completely be ignored...

26. Identifying who interrupts (1) zDifferent hardware line for each module yLimits number of devices zSoftware poll yCPU asks each module in turn (interrupt controller in the middle) ySlow

27. Identifying who interrupts (2) zDaisy Chain or Hardware poll yInterrupt Acknowledge sent down a chain yModule responsible places vector on bus yCPU uses vector to identify handler routine zBus Master yModule must claim the bus before it can raise interrupt ye.g. PCI & SCSI

28. Vectored interrupt  Associate unique starting address with each line or send special code over I/O bus (so that single request line is used)  This may be indirect (instead of using to code to figure out the service routine address, the address found by translating the code contains the service routine address)  When CPU receives a interrupt request, it may be in the midst of processing an atomic instruction or serving high priority job, so it acknowledges that it is ready to serve...

29. Figuring out Interrupt Service Address zCPU gets the code or the vector zthen applies some simple function to map this to a number that contains the address of service routine. zfor example, in 8088, it can interface with 256 devices, and handing addresses are stored in a table at the top of the memory from 0 to 1016 (each entry needs 4 bytes). zso we can think device i has code i zif device 5 interrupts, it will send 5 as its vector, and we multiply it by 4 zaddress 20 will contain the address of service routine for device 5

30. Multiple Interrupts zEach interrupt line has a priority zHigher priority lines can interrupt lower priority lines

31. Interrupt Priorities (1) zFor instance, a timer must have very high priority so that the time is kept right... zIf CPU polls on devices upon interrupt request, device that is polled first gets served first zIn a daisy chain where interrupt request acknowledge line is chained among devices (the acknowledge passes through the devices until reaching the first device requesting the interrupt). The first device electrically close to the CPU gets served first... (Closer the device is chained, the higher its priority priority)

32. Interrupt Priorities (2) zA priority handling circuitry can be made to accept from multiple request lines (one request per device for example) and the priority handling circuit determines who to serve by sending the acknowledge signal to the device with highest priority. This method is more flexible but requires more hardware zAnd, of course, the daisy chain and priority handling circuitry can be mixed... (several devices daisy chained for one priority group)...

33. Interrupt during Interrupt (1) zIgnore any interrupt during interrupt service, or zAllow higher priority to be served yJump to higher priority interrupt service routine as usual  Save information about any incoming lower priority interrupt requests in a stack as pending so that these can be served after the high priority ones are served

34. Interrupt during Interrupt (2) e.g. 3 devices: printer (2), disk (4), serial device (5), numbers in bracket are prorities... ---------------------------------------------------------------------------------------- time | | | | | | A B C D E F A: printer interrupts and CPU starts serving it B: serial device interrupts and since it has higher priority, printer service is stopped and serial device is served C: disk interrupts but since it has lower than currently running service routine, it pends (information saved on stack, or …) D: serial device service ends, returns to it jumped from the printer service routine, checks for any pending interrupt, finds disk is pending and since it has higher priority than printer, starts service it E: disk service ends, printer service continues F: printer service ends, returns to normal CPU execution

35. Exception  Interrupts are generated internally by CPU)  When ?  Some undesirable CPU state (divide by zero, illegal memory access, etc) like external events, they must be servied by interrupt routines zTherefore, they too have vector numbers associated with types of exceptions which would be higher priority than user external interrupts, and their address table is located with the address table for the user external interrupts

36. Example - PC Bus z80x86 has one interrupt line z8086 based systems use one 8259A interrupt controller z8259A has 8 interrupt lines

37. Sequence of Events z8259A accepts interrupts z8259A determines priority z8259A signals 8086 (raises INTR line) zCPU Acknowledges z8259A puts correct vector on data bus zCPU processes interrupt

38. PC Interrupt Layout 8086 INTR 8259A IRQ0 IRQ1 IRQ2 IRQ3 IRQ4 IRQ5 IRQ6 IRQ7

39. ISA Bus Interrupt System zISA bus chains two 8259As together zLink is via interrupt 2 zGives 15 lines y16 lines less one for link zIRQ 9 is used to re-route anything trying to use IRQ 2 yBackwards compatibility zIncorporated in chip set

40. ISA Interrupt Layout 80x86 INTR 8259A IRQ0 IRQ1 IRQ2 IRQ3 IRQ4 IRQ5 IRQ6 IRQ7 8259A IRQ0 (8) IRQ1 (9) IRQ2 (10) IRQ3 (11) IRQ4 (12) IRQ5 (13) IRQ6 (14) IRQ7 (15) (IRQ 2)

42. Figuring out Interrupt Service Address (2) z80286/386 does it similarly except the table can lie anywhere (not necessarily at the top of the memory). The CPU gets 8 byte segment descriptors (to specify where the table is) and some code that basically offsets from the top of the table pointed by the segment descriptors... zIntel uses hardwired priority (a priority handling chip 8259 is used and high priority device must connect specific pins on this chip)

43. Figuring out Interrupt Service Address (3) z5 priority levels: 1. Reset 2. Internal interrupts / Exceptions 3. Software interrupts 4. Nonmaskable interrupts 5. External hardware interrupts zAmong same group, the machine checks for the type number (vector number) which numbers from 0 to 255 (256 interrupts possible) zFor each vector, the starting address is stored at the top of the memory (memory location 0 to 255*4) zFor each vector, 4 bytes are needed, 2 for the segment address and 2 for the offset (IP)

47. Interrupt Control Instructions

57. Exceptional Control Flow zLow level Mechanism yexceptions xchange in control flow in response to a system event (i.e., change in system state) yCombination of hardware and OS software zHigher Level Mechanisms yProcess context switch ySignals yNonlocal jumps (setjmp/longjmp) yImplemented by either: xOS software (context switch and signals). xC language runtime library: nonlocal jumps.

58. System context for exceptions Local/IO Bus Memory Network adapter Network adapter IDE disk controller IDE disk controller Video adapter Video adapter Display Network Processor Interrupt controller Interrupt controller SCSI controller SCSI controller SCSI bus Serial port controller Serial port controller Parallel port controller Parallel port controller Keyboard controller Keyboard controller Keyboard Mouse Printer Modem disk CDROM

59. Exceptions zAn exception is a transfer of control to the OS in response to some event (i.e., change in processor state) User ProcessOS exception exception processing by exception handler exception return (optional) event current next

60. Asynchronous Exceptions (Interrupts) zCaused by events external to the processor yIndicated by setting the processor’s interrupt pin yhandler returns to “next” instruction. zExamples: yI/O interrupts xhitting ctl-c at the keyboard xarrival of a packet from a network xarrival of a data sector from a disk yHard reset interrupt xhitting the reset button ySoft reset interrupt xhitting ctl-alt-delete on a PC

61. Synchronous Exceptions zCaused by events that occur as a result of executing an instruction: yTraps xIntentional xExamples: system calls, breakpoint traps, special instructions xReturns control to “next” instruction yFaults xUnintentional but possibly recoverable xExamples: page faults (recoverable), protection faults (unrecoverable). xEither re-executes faulting (“current”) instruction or aborts. yAborts xunintentional and unrecoverable xExamples: parity error, machine check. xAborts current program

62. Trap Example (system call) zOpening a File  User calls open(filename, options)  Function open executes system call instruction int yOS must find or create file, get it ready for reading or writing yReturns integer file descriptor 0804d070 :... 804d082:cd 80 int $0x80 804d084:5b pop %ebx...

63. Trap Example User ProcessOS exception Open file return int pop

64. Fault Example #1 zMemory Reference yUser writes to memory location yThat portion (page) of user’s memory is currently on disk yPage handler must load page into physical memory yReturns to faulting instruction ySuccessful on second try

65. Fault Example #1 User ProcessOS page fault Create page and load into memory return event movl int a[1000]; main () { a[500] = 13; } 80483b7:c7 05 10 9d 04 08 0d movl $0xd,0x8049d10

66. Fault Example #2 zMemory Reference yUser writes to memory location yAddress is not valid yPage handler detects invalid address  Sends SIGSEG signal to user process yUser process exits with “segmentation fault”

67. Fault Example #2 User ProcessOS page fault Detect invalid address event movl int a[1000]; main () { a[5000] = 13; } 80483b7:c7 05 60 e3 04 08 0d movl $0xd,0x804e360 Signal process

68. Direct Memory Access zInterrupt driven and programmed I/O require active CPU intervention yTransfer rate is limited yCPU is tied up zDMA is the answer

69. DMA Function zAdditional Module (hardware) on bus zDMA controller takes over from CPU for I/O

70. DMA Operation zCPU tells DMA controller:- yRead/Write yDevice address yStarting address of memory block for data yAmount of data to be transferred zCPU carries on with other work zDMA controller deals with transfer zDMA controller sends interrupt when finished

71. DMA Transfer Cycle Stealing zDMA controller takes over bus for a cycle zTransfer of one word of data zNot an interrupt yCPU does not switch context zCPU suspended just before it accesses bus yi.e. before an operand or data fetch or a data write zSlows down CPU but not as much as CPU doing transfer

72. DMA Configurations (1) zSingle Bus, Detached DMA controller zEach transfer uses bus twice yI/O to DMA then DMA to memory zCPU is suspended twice CPU DMA Controller I/O Device I/O Device Main Memory

73. DMA Configurations (2) zSingle Bus, Integrated DMA controller zController may support >1 device zEach transfer uses bus once yDMA to memory zCPU is suspended once CPU DMA Controller I/O Device I/O Device Main Memory DMA Controller I/O Device

74. DMA Configurations (3) zSeparate I/O Bus zBus supports all DMA enabled devices zEach transfer uses bus once yDMA to memory zCPU is suspended once CPU DMA Controller I/O Device I/O Device Main Memory I/O Device I/O Device

75. I/O Channels zI/O devices getting more sophisticated ze.g. 3D graphics cards zCPU instructs I/O controller to do transfer zI/O controller does entire transfer zImproves speed yTakes load off CPU yDedicated processor is faster