1 / 18

Input and Output Programming

Input and Output Programming. Classical IO devices CPU and IO Interfacing Other Input/Output programming. C hapter 11 Input and Output, Goodman and Miller. Input and Output. Computers and programs have to interact with the external world.

llewellyn-timothy
Download Presentation

Input and Output Programming

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. Input and Output Programming • Classical IO devices • CPU and IO Interfacing • Other Input/Output programming Chapter 11 Input and Output, Goodman and Miller CMPUT 229

  2. Input and Output • Computers and programs have to interact with the external world. • Controlling devices (e.g., sensors) is still one of the major reasons for using assembling languages. • Most I/O devices have a mechanical component making them relatively slow compared to the execution of an instruction. CMPUT 229

  3. Classes of IO Devices • User Interface Devises • Keyboard, mouse, display, printer • Mass storage devises • Hard disc, CD, type driver • Bottom of the memory hierarchy • Gateways and networks • Network protocol • security CMPUT 229

  4. All I/O devices are unpredictable • All I/O devices have their own rate for accepting or generating data • Computers and programs must accommodate themselves to the I/O devices CMPUT 229

  5. Interface between CPU and IO • Primitive input/output “instructions • Syscall • More like function calls • privileged system mode • system level routines provide for efficient and fair usage • Programmed input/output • Asynchronous I/O • Direct Memory Access (DMA) CMPUT 229

  6. Memory mapped input/output • Simple I/O devices appear superficially like memory • - read/write data to/from a device • How to communicate with I/O? • Treat I/O devises like memory locations • Read: load from the relevant memory • Write: save to the relevant memory • Hardware support (drivers) • intercept the special addresses and treat the operation correctly CMPUT 229

  7. For example lw $2, Keyboard # Read from the keyboard Sw $4, DisplayData # Write to the display • Is the device ready/available ? • An input is ready if it has something to supply • An output is ready if it can accept something • Solutions: each i/o device has two memory units • Status/control variable: to indicate the readyness • Data (buffer): to store the data to be input or to output CMPUT 229

  8. Programmed I/O (busy-waiting) • A simple and extremely inefficient approach is to have the CPU wait or "spin" until the device becomes ready • Reading the Keyboard #------------------------------------------------------ # Read a character from the keyboard into $2 # Bit 31 (MSB) of KeyboardStatus will be set to 1 # when there is a character to read #---------------------------------------------------- Spin: lw $14, KeyboardStatus bgez $14, Spin lw $2, KeyboardData CMPUT 229

  9. Writing to the Display #---------------------------------------- # Write the character in $2 to the display # Bit 31 (MSB) of DisplayStatus will be set to 1 # when the display is ready to accept a character #------------------------------------------------------ Spin: lw $14, DisplayStatus bgez $14, Spin sw $2, DisplayData CMPUT 229

  10. Asynchronous I/O • Programmed I/O is extremely inefficient. Also characters can be lost if device not checked when it has input. • Idea of asynchronous I/O is that CPU does not wait for device to become ready. CMPUT 229

  11. Example: Printing #------------------------------------------------------- # Procedure: PutNextChar # Based on Goodman & Millar, p. 301 # If the Display is ready # grab next character from queue, update the queue, and send it to the display #------------------------------------------------------- .data putqueue: .space 256 pqt: .word 0 # TAIL of Put Queue pqh: .word 0 # HEAD of Put Queue .text PutNextChar: lw $14, DisplayStatus bgez $14, putret # Device not ready lw $26, pqh # Get queue head lw $27, pqt # & tail beq $26, $27, putret # Queue empty addi $26, $26, 1 # (head += 1) % 256 andi $26, $26, 0xff sw $26, pqh lb $26, putqueue($26) # Get head of queue sw $26, DisplayData putret: jr $31 CMPUT 229

  12. PrintingString • loads up queue and initially calls PutNextChar • Main program may periodically call PutNextChar to drive the I/O device CMPUT 229

  13. Example: Reading #--------------------------------------------------- # Procedure: GetNextChar # Based on Goodman & Millar p. 302 # if there is a character there to read # update the queue, read the character, and store it on the queue #----------------------------------------------------------- .data getqueue: .space 256 gqt: .word 0 # TAIL of Get Queue gqh: .word 0 # HEAD of Get Queue .text GetNextChar: lw $14, KeyBoardStatus bgez $14, getret # Device not ready lw $26, gqt # Get queue tail lw $27, gqh # & head addi $26, $26, 1 # (gqt+=1) % 256 andi $26, $26, 0xff beq $26, $27, getret # Queue is full sw $26, gqt lw $27, KeyboardData sb $27, getqueue($26) getret: jr $31 CMPUT 229

  14. GetNextChar called periodically by main program to "drive" the device • Higher level routine GetString accesses the queue when data is needed • GetString can busy-wait on GetNextChar if not enough data available CMPUT 229

  15. Problems: • programmer is responsible for calling the routines to "drive" the devices • time of main program execution and I/O device readiness is still unpredictable • considerable wastage of both CPU and possible loss of data can still occur CMPUT 229

  16. Direct Memory Access (DMA) • to have a simple computer or controller (or channel) load the data directly into memory. • CPU assigns a task to the controller which then loads (or takes) the memory from a set memory location. • Controller has: • - status register/location for indicating completion • - control register/location so CPU can indicate the task requested • CPU supplies both the start memory address and number of bytes to the controller CMPUT 229

  17. Example: Read a block of data from Disc #--------------------------------------------------- # A DMA controller's code to transfer 1k of data into memory beginning at location 0x4400. # Based on Goodman & Millar p. 304 with assumption that memory has already been allocated. #--------------------------------------------------------- .data Count: .word 1024 # Nbytes to transfer Begin_file .word 0x4400 # Memory location at # which load begins .text Initialise: lw $15, Count lw $16, Begin_file # different to text Loop: lw $14, DiskStatus bgez $14, Wait # Device not ready lb $2, DiskData # Get a byte & sb $2, ($16) # store it sub $15, $15, 1 # Count -= 1 add $16, $16, 1 # Point to next memory # location bgtz $15, Loop CMPUT 229

  18. CPU initialises DMA controller at start of task • CPU periodically checks status of controller to see whether task is completed CMPUT 229

More Related