CMSC 412 Lecture 2: Computer Systems and I/O Systems - Prof. Jeffrey K. Hollingsworth, Study notes of Operating Systems

Download CMSC 412 Lecture 2: Computer Systems and I/O Systems - Prof. Jeffrey K. Hollingsworth and more Study notes Operating Systems in PDF only on Docsity!

Announcements

z^

Program #0– its due Thursday

z^

Reading– Chapter 2– Chapter 3 (for Tuesday)

Computer Systems

z^

Computers have many different devices– I/O Devices– Memory

• volatile storage
  • Processor(s)

Processor

Memory Mem. Controller

I/O Bus Controller

Memory Bus

I/O Bus

Display Adapter

SCSI Adapter

SCSI Bus

Disk Drives

Tape Drive

Optical Drive

Network Adapter

Network

Different Requirements lead to Multiple

Buses

z^

Processor Bus (on chip)– Many Gigabytes/sec

z^

Memory Bus (on processor board)– ~1-2 Gigabyte per second

z^

I/O Bus (PCI, MCA)– ~100 megabytes per second– buses are more complex than we saw in class

• show PCI spec.

z^

Device Bus (SCSI, USB)– tens of megabytes per second

Issues In Busses

z^

Performance– increase the data bus width– have separate address and data busses– block transfers

• move multiple words in a single request

z^

Who controls the bus?– one or more bus masters

• a bus master is a device that can initiate a bus request
  • need to arbitrate who is the bus master
    • assign priority to different devices• use a protocol to select the highest priority item
      • daisy chained– central control

I/O Interfaces

z^

Need to adapt Devices to CPU speeds

z^

Moving the data– Programmed I/O

• Special instructions for I/O
  • Mapped I/O
    • looks like memory only slower
      • DMA (direct memory access)
        • device controller can write to memory• processor is not required to be involved• can grab bus bandwidth which can slow the processor down

I/O Interrupts

z^

Interrupt defined– indication of an event– can be caused by hardware devices

• indicates data present or hardware free
  • can be caused by software
    • system call (or trap)
      • CPU stops what it is doing and executes a handler function
        • saves state about what was happening• returns where it left off when the interrupt is done

z^

Need to know what device interrupted– could ask each device (slow!)– instead use an interrupt vector

• array of pointers to functions to handle a specific interrupt

System Calls

z^

Provide the interface between application programsand the kernel

z^

Are like procedure calls– take parameters– calling routine waits for response

z^

Permit application programs to access protectedresources

load r0, xsystem call 10User Program

Operating System

Code forsys call 10 (kernel)

register r

System Call Mechanism

z^

Use numbers to indicate what call is made

z^

Parameters are passed in registers or on the stack

z^

Why do we use indirection of system call numbersrather than directly calling a kernel subroutine?– provides protection since the only routines available are

those that are export

• permits changing the size and location of system call

implementations without having to re-link applicationprograms

I/O Operations

z^

Synchronous I/O– program traps into the OS– request is made to the device– processor waits for the device– request is completed– processor returns to application process

z^

Asynchronous I/O– request is made to the device– processor records request– processor continues program

• could be a different one
  • request is completed and device interrupts– processor records that request is done– program execution continues