Presentation is loading. Please wait.

Presentation is loading. Please wait.

Advanced Programming for 3D Applications CE00383-3 Bob Hobbs Staffordshire university Data Capture, Streams and Devices Lecture 11.

Similar presentations


Presentation on theme: "Advanced Programming for 3D Applications CE00383-3 Bob Hobbs Staffordshire university Data Capture, Streams and Devices Lecture 11."— Presentation transcript:

1 Advanced Programming for 3D Applications CE00383-3 Bob Hobbs Staffordshire university Data Capture, Streams and Devices Lecture 11

2 2 Rationale We get data from files, sensors, web connections, etc., which we want to analyze, print, graph, etc. We get data from files, sensors, web connections, etc., which we want to analyze, print, graph, etc. Sometimes, we want to produce such data and output to devices. Sometimes, we want to produce such data and output to devices.

3 3 I/O devices - terminology Device (mechanical hardware) Device (mechanical hardware) Device controller (electrical hardware) Device controller (electrical hardware) Device driver (software) Device driver (software)

4 4 Example devices and their controllers Components of a simple personal computer Components of a simple personal computer Monitor Bus

5 5 Device controllers The Device vs. its Controller The Device vs. its Controller Some duties of a device controller: Some duties of a device controller: –Interface between CPU and the Device –Start/Stop device activity –Convert serial bit stream to a block of bytes –Deal with errors Detection / Correction Detection / Correction –Move data to/from main memory Some controllers may handle several (similar) devices Some controllers may handle several (similar) devices

6 6 Input and Output input device device driver input library our program output librarydevice driver output device data source: data destination:

7 7 The stream model An ostream An ostream –turns values of various types into character sequences –sends those characters somewhere E.g., console, file, main memory, another computer E.g., console, file, main memory, another computer c (1,234) 123 ostream buffer “somewhere”

8 8 The stream model An istream An istream –turns character sequences into values of various types –gets those characters from somewhere E.g., console, file, main memory, another computer E.g., console, file, main memory, another computer c (1,234) 123 istream buffer “somewhere”

9 9 The stream model Reading and writing Reading and writing –Of typed entities > (input) plus other operations > (input) plus other operations Type safe Type safe Formatted Formatted –Typically stored (entered, printed, etc.) as text But not necessarily - possibly binary. But not necessarily - possibly binary. –Extensible You can define your own I/O operations for your own types You can define your own I/O operations for your own types –A stream can be attached to any I/O or storage device

10 10 I/O Devices The are two categories of the I/O devices: The are two categories of the I/O devices: –Block Devices store and deliver information in blocks of bytes Disk uses fixed-size blocks Disk uses fixed-size blocks Tape and asynchronous terminals use variable size blocks Tape and asynchronous terminals use variable size blocks –Character Devices (dumb terminals, keypunch, card readers, printers, MIDI) store and deliver information as a stream of bytes And then there are devices (e.g., computer clocks, telemetric devices, etc.) that don’t belong to these categories.

11 11 Device Controllers and I/O Channels The programmable component of a device is called a controller. Controllers connect to the system bus The programmable component of a device is called a controller. Controllers connect to the system bus In some cases, a separate CPU is assigned to deal with a device (or a set of devices). Such a CPU and its supporting circuitry form an I/O Channel In some cases, a separate CPU is assigned to deal with a device (or a set of devices). Such a CPU and its supporting circuitry form an I/O Channel

12 12 Device Controllers and I/O Channels (cont.) CPUMemoryDevice Controller Device... CPUMemory CPU Memory Device Controller Device... I/O Channel

13 13 Interfaces and Responsibilities (OS) CPU Device Controller Device A serial bit stream delineated by a preamble and a checksum A block of data (can be transferred via a serial byte stream) A device controller is responsible for 1.Ensuring that the I/O is error free and 2.Translating the OS requests into a series of low-level device commands and vice versa

14 14 How to communicate with a device? Hardware supports I/O ports or memory mapped I/O for accessing device controller registers and buffers Hardware supports I/O ports or memory mapped I/O for accessing device controller registers and buffers

15 15 I/O ports Each port has a separate number. Each port has a separate number. CPU has special I/O instructions CPU has special I/O instructions – in r4,3 – out 3,r4 Port numbers form an “address space”... separate from main memory Port numbers form an “address space”... separate from main memory Contrast with Contrast with – load r4,3 – store 3,r4 The I/O Port Number

16 16 Memory-mapped I/O One address space for One address space for –main memory –I/O devices CPU has no special instructions CPU has no special instructions – load r4,addr – store addr,r4 I/O devices are “mapped” into I/O devices are “mapped” into – very high addresses 0x00000000 0xFFFF0000 0xFFFFFFFF Physical Installed Memory I/O Devices

17 17 Wide range of I/O device speeds

18 18 Performance challenges: I/O hardware How to prevent slow devices from slowing down memory due to bus contention How to prevent slow devices from slowing down memory due to bus contention –What is bus contention? How to access I/O addresses without interfering with memory performance How to access I/O addresses without interfering with memory performance

19 19 Single vs. dual bus architecture

20 20 Performance challenges: I/O software How to prevent CPU throughput from being limited by I/O device speed (for slow devices) How to prevent CPU throughput from being limited by I/O device speed (for slow devices) –Why would slow devices affect the CPU? How to prevent I/O throughput from being limited by CPU speed (for fast devices) How to prevent I/O throughput from being limited by CPU speed (for fast devices) –Why would device throughput be limited by the CPU? How to achieve good utilization of CPU and I/O devices How to achieve good utilization of CPU and I/O devices How to meet the real-time requirements of devices How to meet the real-time requirements of devices

21 21 Programmed I/O Steps in printing a string

22 22 Programmed I/O Example: Example: –Writing a string to a serial output Printing a string on the printer CopyFromUser(virtAddr, kernelBuffer, byteCount) for i = 0 to byteCount-1 while *serialStatusReg != READY while *serialStatusReg != READY endWhile endWhile *serialDataReg = kernelBuffer[i] *serialDataReg = kernelBuffer[i]endForreturn Called “Busy Waiting” or “Polling” Called “Busy Waiting” or “Polling” Problem: CPU is continually busy working on I/O! Problem: CPU is continually busy working on I/O!

23 23 Interrupt-Driven I/O Getting the I/O started: Getting the I/O started: CopyFromUser(virtAddr, kernelBuffer, byteCount) EnableInterrupts() while *serialStatusReg != READY endWhile *serialDataReg = kernelBuffer[0] Sleep () The Interrupt Handler: The Interrupt Handler: if i == byteCount Wake up the user process Wake up the user processelse *serialDataReg = kernelBuffer[i] *serialDataReg = kernelBuffer[i] i = i + 1 i = i + 1endIf Return from interrupt

24 24 Hardware support for interrupts How interrupts happen. Connections between devices and interrupt controller actually use interrupt lines on the bus rather than dedicated wires

25 25 Problem with Interrupt driven I/O Problem: Problem: –CPU is still involved in every data transfer –Interrupt handling overhead is high –Overhead cost is not amortized over much data –Overhead is too high for fast devices Gbps networks Gbps networks Disk drives Disk drives

26 26 Direct Memory Access (DMA) DMA solves the problem by transferring the data between the main memory and the controller’ buffer without getting the CPU (and OS) involved beyond ordering a transfer DMA solves the problem by transferring the data between the main memory and the controller’ buffer without getting the CPU (and OS) involved beyond ordering a transfer A DMA (which could be a separate device or part of the device controller) accesses main memory by stealing cycles from CPU A DMA (which could be a separate device or part of the device controller) accesses main memory by stealing cycles from CPU

27 27 Direct Memory Access (DMA) Data transferred from device straight to/from memory Data transferred from device straight to/from memory CPU not involved CPU not involved The DMA controller: The DMA controller: –Does the work of moving the data –CPU sets up the DMA controller (“programs it”) –CPU continues –The DMA controller moves the bytes

28 28 Sending data to a device using DMA Getting the I/O started: Getting the I/O started: CopyFromUser(virtAddr, kernelBuffer, byteCount) Set up DMA controller Sleep () The Interrupt Handler: The Interrupt Handler: Acknowledge interrupt Wake up the user process Return from interrupt

29 29 Direct Memory Access (DMA)

30 30 Cycle Stealing Cycle Stealing –DMA Controller acquires control of bus –Transfers a single byte (or word) –Releases the bus –The CPU is slowed down due to bus contention Burst Mode Burst Mode –DMA Controller acquires control of bus –Transfers all the data –Releases the bus –The CPU operation is temporarily suspended

31 31 Direct Memory Access (DMA) Cycle Stealing Cycle Stealing –DMA controller acquires control of bus –Transfers a single byte (or word) –Releases the bus –The CPU is slowed down due to bus contention –Responsive but not very efficient Burst Mode Burst Mode –DMA Controller acquires control of bus –Transfers all the data –Releases the bus –The CPU operation is suspended –Efficient but interrupts may not be serviced in a timely way

32 32 Principles of I/O software Device Independence Device Independence –Programs can access any I/O device Hard Drive, CD-ROM, Floppy,... Hard Drive, CD-ROM, Floppy,...... without specifying the device in advance... without specifying the device in advance Uniform Naming Uniform Naming –Devices / Files are named with simple strings –Names should not depend on the device Error Handling Error Handling –...should be as close to the hardware as possible –… because its often device-specific

33 33 Principles of I/O software Synchronous vs. Asynchronous Transfers Synchronous vs. Asynchronous Transfers –Process is blocked vs. interrupt-driven or polling approaches Buffering Buffering –Data comes off a device –May not know the final destination of the data e.g., a network packet... Where to put it??? e.g., a network packet... Where to put it??? Sharable vs. Dedicated Devices Sharable vs. Dedicated Devices –Disk should be sharable –Keyboard, Screen dedicated to one process

34 34 Software engineering-related challenges How to remove the complexities of I/O handling from application programs How to remove the complexities of I/O handling from application programs –Solution standard I/O APIs (libraries and system calls) standard I/O APIs (libraries and system calls) How to support a wide range of device types on a wide range of operating systems How to support a wide range of device types on a wide range of operating systems –Solution standard interfaces for device drivers (DDI) standard interfaces for device drivers (DDI) standard/published interfaces for access to kernel facilities (DKI) standard/published interfaces for access to kernel facilities (DKI)

35 35 I/O software layers

36 36

37 37 Interrupt handling I/O Device Driver starts the operation I/O Device Driver starts the operation –Then blocks until an interrupt occurs –Then it wakes up, finishes, & returns The Interrupt Handler The Interrupt Handler –Does whatever is immediately necessary –Then unblocks the driver Example: The BLITZ “DiskDriver” Example: The BLITZ “DiskDriver” –Start I/O and block (waits on semaphore) –Interrupt routine signals the semaphore & returns

38 38 Interrupt handlers – top/bottom halves Interrupt handlers are divided into scheduled and non scheduled tasks Interrupt handlers are divided into scheduled and non scheduled tasks Non-scheduled tasks execute immediately on interrupt and run in the context of the interrupted thread Non-scheduled tasks execute immediately on interrupt and run in the context of the interrupted thread –Ie. There is no VM context switch –They should do a minimum amount of work so as not to disrupt progress of interrupted thread –They should minimize time during which interrupts are disabled Scheduled tasks are queued for processing by a designated thread Scheduled tasks are queued for processing by a designated thread –This thread will be scheduled to run later –May be scheduled preemptively or nonpreemptively

39 39 Basic activities of an interrupt handler  Set up stack for interrupt service procedure  Ack interrupt controller, reenable interrupts  Copy registers from where saved  Run service procedure

40 40 I/O software layers

41 41 Device drivers in kernel space

42 42 Device drivers Device drivers are device-specific software that connects devices with the operating system Device drivers are device-specific software that connects devices with the operating system –Typically a nasty assembly-level job Must deal with hardware-specific details (and changes) Must deal with hardware-specific details (and changes) Must deal with O.S. specific details (and changes) Must deal with O.S. specific details (and changes) –Goal: hide as many device-specific details as possible from higher level software Device drivers are typically given kernel privileges for efficiency Device drivers are typically given kernel privileges for efficiency –Bugs can bring down the O.S.! –Open challenge: how to provide efficiency and safety???

43 43 I/O software layers

44 44 Device-independent I/O software Functions and responsibilities Functions and responsibilities –Uniform interfacing for device drivers –Buffering –Error reporting –Allocating and releasing dedicated devices –Providing a device-independent block size

45 45 Device-independent I/O software Device Driver Interface (DDI) and Device Kernel Interface (DKI) without/with standardization

46 46 Device-independent I/O software buffering (a) Unbuffered input (b) Buffering in user space (c) Buffering in the kernel followed by copying to user space (d) Double buffering in the kernel

47 47 Copying overhead in network I/O Networking may involve many copies

48 48 Devices as files Before mounting, Before mounting, –files on floppy are inaccessible After mounting floppy on b, After mounting floppy on b, –files on floppy are part of file hierarchy

49 49 I/O software layers

50 50 User-space I/O software In user’s (C) program In user’s (C) program count = write (fd, buffer, nbytes); printf (“The value of %s is %d\n”, str, i); Linked with library routines. Linked with library routines. The library routines contain: The library routines contain: –Lots of code –Buffering –The syscall to trap into the kernel

51 51 Communicating across the I/O layers

52 52 Some example I/O devices Timers Timers Terminals Terminals Graphical user interfaces Graphical user interfaces Network terminals Network terminals

53 53 Terminals There are three basic types: There are three basic types: 1.Memory-mapped terminals 2.Serial (synchronous) terminals connected over the RS-232 interface 3.Asynchronous terminals (although they have been pretty much replaced by PCs now), which support messages of various length Keyboard and display are two separate devices, and are treated as such by the operating system Keyboard and display are two separate devices, and are treated as such by the operating system

54 54 Musical Instrument Digital Interface (MIDI) Devices In August of 1983, music manufacturers agreed on a document that is called "MIDI 1.0 Specification". In August of 1983, music manufacturers agreed on a document that is called "MIDI 1.0 Specification". The MIDI protocol supports interworking of keyboards, synthesizers, and sequencers built by different manufacturers The MIDI protocol supports interworking of keyboards, synthesizers, and sequencers built by different manufacturers It is important to remember that MIDI transmits commands--not audio signals It is important to remember that MIDI transmits commands--not audio signals

55 55 Physical Interface MIDI uses serial interface. The serial interface was chosen by MIDI manufacturers because it is less expensive than parallel interface. MIDI uses serial interface. The serial interface was chosen by MIDI manufacturers because it is less expensive than parallel interface. The speed of a MIDI serial interface is 31,250 bits per second. The speed of a MIDI serial interface is 31,250 bits per second. There are 10 bits needed for every MIDI digital word or 3125 messages per second. There are 10 bits needed for every MIDI digital word or 3125 messages per second.

56 56 MIDI Data examples Note on/off (on a particular channel) Note on/off (on a particular channel) Additional effects (like sustain pedal) Additional effects (like sustain pedal) Dynamic range of the note Dynamic range of the note 903C72 Note ON, Channel 1 Middle C Velocity: 72

57 57 Principles of the I/O Software Design 1. Device independence –At the user-level, the API is as abstract as possible (e.g., sort output ) –All device-specific code goes into device drivers 2. Uniform Naming (whence Universal Resource Identifier [URI] came)

58 58 Life Cycle of an I/O Request

59 59 Summary Input / Output required to allow user interaction with applications Input / Output required to allow user interaction with applications Similarity between files and devices Similarity between files and devices Systems strive for device independence Systems strive for device independence Allows communication between devices and applications using them to optimise OS control Allows communication between devices and applications using them to optimise OS control Separation of program execution and device function Separation of program execution and device function Control of access to data when required handled by interrupt (for intermittent interaction) or Control of access to data when required handled by interrupt (for intermittent interaction) or Direct interaction for more continuous interaction Direct interaction for more continuous interaction Often a software link – Device driver Often a software link – Device driver Driver has to be written to map data transfer requirements to computer control Driver has to be written to map data transfer requirements to computer control


Download ppt "Advanced Programming for 3D Applications CE00383-3 Bob Hobbs Staffordshire university Data Capture, Streams and Devices Lecture 11."

Similar presentations


Ads by Google