1 / 61

Computer Science 210 s1c Computer Systems 1 2014 Semester 1 Lecture Notes

Lecture 13. Input & Output. Computer Science 210 s1c Computer Systems 1 2014 Semester 1 Lecture Notes. James Goodman (revised by Robert Sheehan). Credits: Slides prepared by Gregory T. Byrd, North Carolina State University. Synchronisation.

fai
Télécharger la présentation

Computer Science 210 s1c Computer Systems 1 2014 Semester 1 Lecture Notes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 13 Input & Output Computer Science 210 s1cComputer Systems 12014Semester 1Lecture Notes James Goodman (revised by Robert Sheehan) Credits: Slides prepared by Gregory T. Byrd, North Carolina State University

  2. 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?

  3. 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

  4. Chapter 8I/O

  5. 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 thathumans can use it?

  6. 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

  7. DeviceBehaviorPartnerData Rate(KB/sec) KeyboardInputHuman0.01 MouseInputHuman0.02 Laser PrinterOutputHuman1,000 Graphics DisplayOutputHuman30,000 Network-LANInput or OutputMachine200-100,000 Internet Input or Output Machine 4,o00- ? CD-ROM (1x)StorageMachine150 DVD-ROM (1x)StorageMachine1,352 Magnetic DiskStorageMachine 100,000 Flash Memory Storage-read Machine 100,000-300,000 Storage-write Machine 50,000-100,000 I/O Device Examples

  8. 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 • Device electronics • performs actual operation • pixels to screen, bits to/from disk, characters from keyboard Graphics Controller Control/Status CPU Electronics display Output Data

  9. 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)

  10. 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

  11. Transfer Timing • I/O events generally happen much slowerthan 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

  12. 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 whennew data arrives OR device ready for next data • CPU can be performing other tasks instead of polling device. • “Wake me when we get there.”

  13. 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

  14. 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 • When KBDR is read: • KBSR[15] is set to zero • keyboard is enabled keyboard data 15 8 7 0 KBDR 15 14 0 ready bit KBSR

  15. Basic Input Routine POLL LDI R0, KBSRPtr BRzp POLL LDI R0, KBDRPtr ... KBSRPtr .FILL xFE00KBDRPtr .FILL xFE02 new char? NO Polling YES readcharacter

  16. Simple Implementation: Memory-Mapped Input Address Control Logic determines whether MDR is loaded from Memory or from KBSR/KBDR.

  17. Output to Monitor • When Monitor is ready to display another character: • the “ready bit” (DSR[15]) is set to one • 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) output data 15 8 7 0 DDR 15 14 0 ready bit DSR

  18. Basic Output Routine POLL LDI R1, DSRPtr BRzp POLL STI R0, DDRPtr ... DSRPtr .FILL xFE04DDRPtr .FILL xFE06 screen ready? NO Polling YES writecharacter

  19. Simple Implementation: Memory-Mapped Output Sets LD.DDR or selects DSR as input.

  20. Keyboard Echo Routine • Usually, input character is also printed to screen. • User gets feedback on character typedand knows its ok to type the next character. new char? POLL1 LDI R0, KBSRPtr BRzp POLL1 LDI R0, KBDRPtrPOLL2 LDI R1, DSRPtr BRzp POLL2 STI R0, DDRPtr ... KBSRPtr .FILL xFE00KBDRPtr .FILL xFE02DSRPtr .FILL xFE04DDRPtr .FILL xFE06 NO YES readcharacter screen ready? NO YES writecharacter

  21. Interrupt-Driven I/O • External device can: • Force currently executing program to stop; • Have the processor satisfy the device’s needs; and • Resume the stopped program as if nothing happened. • Why? • Polling consumes a lot of cycles,especially for rare events – these cycles can be usedfor more computation. • Example: Process previous input while collectingcurrent input. (See Example 8.1 in text.)

  22. Interrupt-Driven I/O • To implement an interrupt mechanism, we need: • A way for the I/O device to signal the CPU that aninteresting event has occurred. • A way for the CPU to test whether the interrupt signal is setand 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 0 15 14 13 ready bit KBSR interrupt signal to processor

  23. 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.

  24. 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

  25. 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.

  26. Review Questions • What is the danger of not testing the DSRbefore writing data to the screen? • What is the danger of not testing the KBSRbefore reading data from the keyboard?What if the Monitor were a synchronous device,e.g., we know that it will be ready 1 microsecond aftercharacter is written. • Can we avoid polling? How? • What are advantages and disadvantages?

  27. 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 accessingdevice registers?

  28. Lecture 14 TRAP routines Computer Science 210 s1cComputer Systems 12014Semester 1Lecture Notes James Goodman (revised by Robert Sheehan) Credits: Slides prepared by Gregory T. Byrd, North Carolina State University

  29. Chapter 9TRAP Routines andSubroutines

  30. System Calls • Certain operations require specialized knowledgeand protection: • specific knowledge of I/O device registersand 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 routinesorsystem calls(part of operating system) to safely and convenientlyperform low-level, privileged operations

  31. 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.

  32. 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

  33. 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

  34. TRAP NOTE: PC has already been incrementedduring instruction fetch stage.

  35. RET (JMP R7) • How do we transfer control back toinstruction 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.

  36. TRAP Mechanism Operation • Lookup starting address. • Transfer to service routine. • Return (JMP R7).

  37. Example: Using the TRAP Instruction • .ORIG x3000 • LD R2, TERM ; Load negative ASCII ‘7’ LD R3, ASCII ; Load ASCII differenceAGAIN TRAP x23 ; input character ADD R1, R2, R0 ; Test for terminateBRz EXIT ; Exit if done ADD R0, R0, R3 ; Change to lowercaseTRAP x21 ; Output to monitor...BRnzpAGAINTERM .FILL xFFc9 ; Additive inverse of ASCII ‘7’ASCII .FILL x0020 ; lowercase bitEXIT TRAP x25 ; halt.END

  38. Example: Output Service Routine • .ORIG x0430 ; syscall address ST R7, SaveR7 ; save R7 & R1 ST R1, SaveR1 • … • ; ----- Write character • TryWrite LDI R1, CRTSR ; get statusBRzpTryWrite ; look for bit 15 onWriteIt STI R0, CRTDR ; write char • … • ; ----- Return from TRAPReturn LD R1, SaveR1 ; restore R1 & R7 LD R7, SaveR7RET ; back to userCRTSR .FILL xFE04 ; DSRCRTDR .FILL xFE06 ; DDRSaveR1 .FILL 0SaveR7 .FILL 0 .END stored in table,location x21

  39. TRAP Routines and their Assembler Names

  40. Example • LEA R3, Binary LD R6, ASCII ; char->digit template LD R7, COUNT ; initialize to 10AGAIN TRAP x23 ; Get char ADD R0, R0, R6 ; convert to number STR R0, R3, #0 ; store number ADD R3, R3, #1 ; incr pointer ADD R7, R7, -1 ; decr counter BRp AGAIN ; more? BRnzp NEXTASCII .FILL xFFD0COUNT .FILL #10Binary .BLKW #10 What’s wrong with this routine?

  41. 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

  42. 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 orby 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.

  43. Question • Can a service routine call another service routine? • If so, is there anything special the calling service routinemust do?

  44. 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 functionsfor non-system (user) code?

  45. 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 tokeep typing it in • divide task among multiple programmers • use vendor-supplied library of useful routines • Most importantly structure your code

  46. 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]

  47. JSR NOTE: PC has already been incrementedduring instruction fetch stage.

  48. JSRR Instruction • Just like JSR, except Register addressing mode. • target address is Base Register • bit 11 specifies addressing mode • What important feature does JSRR providethat JSR does not?

  49. JSRR NOTE: PC has already been incrementedduring instruction fetch stage.

  50. Returning from a Subroutine • RET (JMP R7) gets us back to the calling routine. • just like TRAP

More Related