
Input and Output Operations in Computer Systems
Explore the challenges and synchronization issues related to input and output devices in computer systems. Learn about the behavior of I/O devices, data rates, and examples of different types of I/O devices such as keyboards, printers, and storage devices. Discover how data is processed and exchanged between the computer system and the outside world.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Computer Science 210 s1c Computer Systems 1 2014 Semester 1 Lecture Notes Lecture 13 Input & Output James Goodman (revised by Robert Sheehan) Credits: Slides prepared by Gregory T. Byrd, North Carolina State University 1
Synchronisation What happens if you try to print a file on a printer already in use? What happens if your programme tries to read a character before it s typed? What happens to a sequence of characters you ve type in before you read them? What happens if you send characters to a printer faster than it can accept them? 2
I/O Devices are Cantankerous Many I/O devices have a mechanical component They are very slow relative to electronic speeds They respond when they re ready, not necessarily when it s convenient They may not be willing to wait forever for their input (overrun) The CPU is the slave: it must synchronize 3
Chapter 8 I/O
I/O: Connecting to the Outside World So far, we ve learned how to: compute with values in registers load data from memory to registers store data from registers to memory But where does data in memory come from? And how does data get out of the system so that humans can use it? 5
I/O: Connecting to the Outside World Types of I/O devices characterized by: behavior: input, output, storage input: keyboard, motion detector, network interface output: monitor, printer, network interface storage: disk, CD-ROM data rate: how fast can data be transferred? Latency: how long to get the first byte Bandwidth: rate that data is received 8-6
I/O Device Examples Device Keyboard Mouse Laser Printer Graphics Display Network-LAN Internet CD-ROM (1x) DVD-ROM (1x) Magnetic Disk Flash Memory Behavior Input Input Output Output Input or Output Input or Output Storage Storage Storage Storage-read Storage-write Partner Human Human Human Human Machine Machine Machine Machine Machine Machine Machine Data Rate (KB/sec) 0.01 0.02 1,000 30,000 200-100,000 4,o00- ? 150 1,352 100,000 100,000-300,000 50,000-100,000 7
I/O Controller Control/Status Registers CPU tells device what to do -- write to control register CPU checks whether task is done -- read status register Data Registers CPU transfers data to/from device Graphics Controller Control/Status CPU display Electronics Output Data Device electronics performs actual operation pixels to screen, bits to/from disk, characters from keyboard 8-8
Programming Interface How are device registers identified? Memory-mapped vs. special instructions How is timing of transfer managed? Asynchronous vs. synchronous Who controls transfer? CPU (polling) vs. device (interrupts) 8-9
Memory-Mapped vs. I/O Instructions Instructions designate opcode(s) for I/O register and operation encoded in instruction Memory-mapped assign a memory address to each device register use data movement instructions (LD/ST) for control and data transfer 8-10
Transfer Timing I/O events generally happen much slower than CPU cycles. Synchronous data supplied at a fixed, predictable rate CPU reads/writes every X cycles Asynchronous data rate less predictable CPU must synchronize with device, so that it doesn t miss data or write too quickly 8-11
Transfer Control Who determines when the next data transfer occurs? Polling CPU keeps checking status register until new data arrives OR device ready for next data Are we there yet? Are we there yet? Are we there yet? Interrupts Device sends a special signal to CPU when new data arrives OR device ready for next data CPU can be performing other tasks instead of polling device. Wake me when we get there. 8-12
LC-3 Memory-mapped I/O (Table A.3) Asynchronous devices synchronized through status registers Polling and Interrupts the details of interrupts will be discussed in Chapter 10 8-13
Input from Keyboard When a character is typed: its ASCII code is placed in bits [7:0] of KBDR (bits [15:8] are always zero) the ready bit (KBSR[15]) is set to one keyboard is disabled -- any typed characters will be ignored keyboard data 15 8 7 0 KBDR 1514 0 KBSR ready bit ready bit When KBDR is read: KBSR[15] is set to zero keyboard is enabled 8-14
Basic Input Routine POLL LDI R0, KBSRPtr BRzp POLL LDI R0, KBDRPtr new char? NO ... Polling YES KBSRPtr .FILL xFE00 KBDRPtr .FILL xFE02 read character 8-15
Simple Implementation: Memory-Mapped Input Address Control Logic determines whether MDR is loaded from Memory or from KBSR/KBDR. 8-16
Output to Monitor When Monitor is ready to display another character: the ready bit (DSR[15]) is set to one output data 15 8 7 0 DDR 1514 0 ready bit DSR When data is written to Display Data Register: DSR[15] is set to zero character in DDR[7:0] is displayed any other character data written to DDR is ignored (while DSR[15] is zero) 8-17
Basic Output Routine POLL LDI R1, DSRPtr BRzp POLL STI R0, DDRPtr screen ready? NO ... Polling YES DSRPtr .FILL xFE04 DDRPtr .FILL xFE06 write character 8-18
Simple Implementation: Memory-Mapped Output Sets LD.DDR or selects DSR as input. 8-19
Keyboard Echo Routine Usually, input character is also printed to screen. User gets feedback on character typed and knows its ok to type the next character. POLL1 POLL2 LDI R0, KBSRPtr BRzp POLL1 LDI R0, KBDRPtr LDI R1, DSRPtr BRzp POLL2 STI R0, DDRPtr new char? NO YES read character ... screen ready? NO KBSRPtr .FILL xFE00 KBDRPtr .FILL xFE02 DSRPtr .FILL xFE04 DDRPtr .FILL xFE06 YES write character 8-20
Interrupt-Driven I/O External device can: (1) Force currently executing program to stop; (2)Have the processor satisfy the device s needs; and (3)Resume the stopped program as if nothing happened. Why? Polling consumes a lot of cycles, especially for rare events these cycles can be used for more computation. Example: Process previous input while collecting current input. (See Example 8.1 in text.) 8-21
Interrupt-Driven I/O To implement an interrupt mechanism, we need: A way for the I/O device to signal the CPU that an interesting event has occurred. A way for the CPU to test whether the interrupt signal is set and whether its priority is higher than the current program. Generating Signal Software sets interrupt enable bit in device register. When ready bit is set and IE bit is set, interrupt is signaled. interrupt enable bit 1514 13 0 ready bit KBSR interrupt signal to processor 8-22
Priority Every instruction executes at a stated level of urgency. LC-3: 8 priority levels (PL0-PL7) Example: Payroll program runs at PL0. Nuclear power correction program runs at PL6. It s OK for PL6 device to interrupt PL0 program, but not the other way around. Priority encoder selects highest-priority device, compares to current processor priority level, and generates interrupt signal if appropriate. 8-23
Testing for Interrupt Signal CPU looks at signal between STORE and FETCH phases. If not set, continues with next instruction. If set, transfers control to interrupt service routine (ISR). F NO D interrupt signal? EA YES Transfer to ISR OP EX More details in Chapter 10. S 8-24
Full Implementation of LC-3 Memory-Mapped I/O Because of interrupt enable bits, status registers (KBSR/DSR) must be written, as well as read. 8-25
Review Questions What is the danger of not testing the DSR before writing data to the screen? What is the danger of not testing the KBSR before reading data from the keyboard? What if the Monitor were a synchronous device, e.g., we know that it will be ready 1 microsecond after character is written. Can we avoid polling? How? What are advantages and disadvantages? 8-26
Review Questions Do you think polling is a good approach for other devices, such as a disk or a network interface? What is the advantage of using LDI/STI for accessing device registers? 8-27
Computer Science 210 s1c Computer Systems 1 2014 Semester 1 Lecture Notes Lecture 14 TRAP routines James Goodman (revised by Robert Sheehan) Credits: Slides prepared by Gregory T. Byrd, North Carolina State University 28
Chapter 9 TRAP Routines and Subroutines
System Calls Certain operations require specialized knowledge and protection: specific knowledge of I/O device registers and the sequence of operations needed to use them I/O resources shared among multiple users/programs; a mistake could affect lots of other users! In real systems we layer our programs using abstraction to make our tasks realistic (APIs). We want our programs to work with each other (multiple programs running simultaneously). Not every programmer knows (or wants to know) this level of detail Provide service routines or system calls (part of operating system) to safely and conveniently perform low-level, privileged operations 9-30
System Call 1. User program invokes system call. 2. Operating system code performs operation. 3. Returns control to user program. In LC-3, this is done through theTRAP mechanism. 9-31
LC-3 TRAP Mechanism 1. A set of service routines. part of operating system -- routines start at arbitrary addresses (convention is that system code is below x3000) up to 256 routines 2. Table of starting addresses. stored at x0000 through x00FF in memory called System Control Block in some architectures 3. TRAP instruction. used by program to transfer control to the operating system 8-bit trap vector names one of the 256 service routines 4. A linkage back to the user program. want execution to resume immediately after the TRAP instruction 9-32
TRAP Instruction Trap vector identifies which system call to invoke 8-bit index into table of service routine addresses in LC-3, this table is stored in memory at 0x0000 0x00FF 8-bit trap vector is zero-extended into 16-bit memory address Where to go lookup starting address from table; place in PC How to get back save address of next instruction (current PC) in R7 9-33
TRAP NOTE: PC has already been incremented during instruction fetch stage. 9-34
RET (JMP R7) How do we transfer control back to instruction following the TRAP? We saved old PC in R7. JMP R7 gets us back to the user program at the right spot. LC-3 assembly language lets us use RET (return) in place of JMP R7 . Must make sure that service routine does not change R7, or we won t know where to return. 9-35
TRAP Mechanism Operation 1. Lookup starting address. 2. Transfer to service routine. 3. Return (JMP R7). 9-36
Example: Using the TRAP Instruction .ORIG x3000 LD LD TRAP ADD BRz ADD TRAP BRnzp AGAIN .FILL xFFc9 .FILL x0020 TRAP .END ; Load negative ASCII 7 ; Load ASCII difference ; input character R2, TERM R3, ASCII x23 R1, R2, R0 ; Test for terminate EXIT ; Exit if done R0, R0, R3 ; Change to lowercase x21 ; Output to monitor... AGAIN TERM ASCII EXIT ; Additive inverse of ASCII 7 ; lowercase bit ; halt x25 9-37
Example: Output Service Routine ; syscall address ; save R7 & R1 .ORIG ST ST x0430 R7, SaveR7 R1, SaveR1 ; ----- Write character TryWrite LDI BRzp WriteIt STI ; ----- Return from TRAP Return LD LD RET CRTSR .FILL CRTDR .FILL SaveR1 .FILL SaveR7 .FILL .END ; get status ; look for bit 15 on ; write char R1, CRTSR TryWrite R0, CRTDR ; restore R1 & R7 R1, SaveR1 R7, SaveR7 xFE04 xFE06 0 0 ; back to user ; DSR ; DDR stored in table, location x21 9-38
TRAP Routines and their Assembler Names vector symbol routine x20 GETC read a single character (no echo) x21 OUT output a character to the console x22 PUTS write a string to the console print prompt to console, read and echo character from keyboard x23 IN x25 HALT halt the program 9-39
Example LEA LD LD TRAP ADD STR ADD ADD BRp BRnzp NEXT .FILL xFFD0 .FILL #10 .BLKW #10 R3, Binary R6, ASCII R7, COUNT x23 R0, R0, R6 ; convert to number R0, R3, #0 ; store number R3, R3, #1 ; incr pointer R7, R7, -1 ; decr counter AGAIN ; more? AGAIN ASCII COUNT Binary ; char->digit template ; initialize to 10 ; Get char What s wrong with this routine? 9-40
Saving and Restoring Registers Must save the value of a register if: Its value will be destroyed by service routine, and We will need to use the value after that action. Who saves? caller of service routine? knows what it needs later, but may not know what gets altered by called routine called service routine? knows what it alters, but does not know what will be needed later by calling routine 9-41
Saving and Restoring Registers Called routine -- callee-save Before start, save any registers that will be altered (unless altered value is desired by calling program!) Before return, restore those same registers Calling routine -- caller-save Save registers destroyed by own instructions or by called routines (if known), if values needed later save R7 before TRAP save R0 before TRAP x23 (input character) Or avoid using those registers altogether Values are saved by storing them in memory. 9-42
Question Can a service routine call another service routine? If so, is there anything special the calling service routine must do? 9-43
What about User Code? Service routines provide three main functions: 1. Shield programmers from system-specific details. 2. Write frequently-used code just once. 3. Protect system resources from malicious/clumsy programmers. Are there any reasons to provide the same functions for non-system (user) code? 9-44
Subroutines A subroutine is a program fragment that: lives in user space performs a well-defined task is invoked (called) by another user program returns control to the calling program when finished Like a service routine, but not part of the OS not concerned with protecting hardware resources no special privilege required Reasons for subroutines: reuse useful (and debugged!) code without having to keep typing it in divide task among multiple programmers use vendor-supplied library of useful routines Most importantly structure your code 9-45
JSR Instruction Jumps to a location (like a branch but unconditional), and saves current PC (addr of next instruction) in R7. saving the return address is called linking target address is PC-relative (PC + Sext(IR[10:0])) bit 11 specifies addressing mode (one opcode, two instructions) if =1, PC-relative: target address = PC + Sext(IR[10:0]) if =0, register: target address = contents of register IR[8:6] 9-46
JSR NOTE: PC has already been incremented during instruction fetch stage. 9-47
JSRR Instruction Just like JSR, except Register addressing mode. target address is Base Register bit 11 specifies addressing mode What important feature does JSRR provide that JSR does not? 9-48
JSRR NOTE: PC has already been incremented during instruction fetch stage. 9-49
Returning from a Subroutine RET (JMP R7) gets us back to the calling routine. just like TRAP 9-50