Microprocessor Programming and Application

1
Microprocessor Programming and Application

• Input/Output

2
Input/Output Problems

• Wide variety of peripherals
• Delivering different amounts of data
• At different speeds
• In different formats
• All slower than CPU and RAM
• Need I/O modules

3
Input/Output Module

• Interface to CPU and Memory
• Interface to one or more peripherals

4
External Devices

• Human readable
• Screen, printer, keyboard
• Machine readable
• Monitoring and control
• Communication
• Modem
• Network Interface Card (NIC)

5
I/O Module Function

• Control Timing
• CPU Communication
• Device Communication
• Data Buffering
• Error Detection

6
I/O Steps

• CPU checks I/O module device status
• I/O module returns status
• If ready, CPU requests data transfer
• I/O module gets data from device
• I/O module transfers data to CPU
• Variations for output, DMA, etc.

7
I/O Module Diagram (c.f. Memory)
Systems Bus Interface
External Device Interface
External Device Interface Logic
Data
Data Register
Data Lines
Status
Status/Control Register
Control
Address Lines
Input Output Logic
External Device Interface Logic
Data
Data Lines
Status
Control
8
I/O Module Decisions

• Hide or reveal device properties to CPU
• Support multiple or single device
• Control device functions or leave for CPU
• Also O/S decisions
• e.g. Unix treats everything it can as a file !

9
Input Output Techniques

• Programmed
• Interrupt driven
• Direct Memory Access (DMA)

10
Programmed I/O (a.k.a. polling, busy wait)

• CPU has direct control over I/O
• Sensing status
• Read/write commands
• Transferring data
• CPU waits for I/O module to complete
  operation(busy waiting, that is, CPU does
  nothing really)
• Wastes CPU time

11
Programmed I/O - detail

• CPU requests I/O operation
• I/O module performs operation
• I/O module sets status bits
• CPU checks status bits periodically
• I/O module does not inform CPU directly
• I/O module does not interrupt CPU
• CPU may wait or come back later

12
Programmed I/O - detail

•   i num_of_words_to_send    while ( i ! 0)
      repeat      status read (status_reg)
      until (status 1) / busy waiting /
      i i - 1     send (wordi)   

13
Solutions

• We can employ DMA (direct memory access)
• DMA controller performs faster I/O operations
  (synchronous) upon a request from CPU
• However, what if the I/O wants to initiate I/O
  instead of the CPU (e.g. events, exception, traps
  ...) ?
• We already learned that polling is wasteful (e.g.
  periodically checking the devices to see if they
  want to send data to the CPU)
• Polling will not even work properly if the events
  must be processed right away (e.g. can not wait
  until the CPU checks what the device wants to do)
  ? Allow I/O devices to issue desire to I/O !
  (interrupts)

14
I/O Commands (1)

• CPU issues address
• Identifies module ( device if gt1 per module)
• CPU issues command
• Control - telling module what to do
• e.g. spin up disk
• Test - check status
• e.g. power? Error?
• Read/Write
• Module transfers data via buffer from/to device

15
I/O Commands (2)

• Special Instructions (now rare)
• Input_ch R1 like get character
• print_ch

16
Addressing I/O Devices

• Under programmed I/O data transfer is very like
  memory access (CPU viewpoint)
• Each device given unique identifier
• CPU commands contain identifier (address)

17
I/O Mapping

• Memory mapped I/O
• Devices and memory share an address space
• I/O looks just like memory read/write
• No special commands for I/O
• Large selection of memory access commands
  available
• Isolated I/O
• Separate address spaces
• Need I/O or memory select lines
• Special commands for I/O
• Limited set

18
Interrupt Driven I/O

• Overcomes CPU waiting
• No repeated CPU checking of device
• I/O module interrupts when ready
• A way of I/O devices to alert the CPU by
  activating one of the control lines (Interrupt
  Request) of the CPU
• Then, CPU "services" the interrupt and returns to
  its normal processing state.  CPU does not poll
  on anything because the devices can raise
  interrupt any time they want (Asynchronous)?
  similar to procedure call ! (think of the exam
  problem)

19
(No Transcript)
20
Interrupt Driven I/OBasic Operation

• CPU issues read command
• I/O module gets data from peripheral whilst CPU
  does other work
• I/O module interrupts CPU
• CPU requests data
• I/O module transfers data
• ? a bit more efficient also (aside from the
  advantage of allowing I/O device to request I/O
  operations)

21
Non-DMA interrupt driven I/O with interrupt where
the CPU computes something to be printed out
continuously

• CPU computes few lines of output
• PRINT sends few lines of text for output
• CPU continues to compute
• PRINT ready interrupts and CPU sends few more
  lines for output
• CPU continues to compute

22
CPU Viewpoint

• Issue read command
• Do other work
• Check for interrupt at end of each instruction
  cycle
• Add this to fetch-decode-execute-store cycle)?
  fetch decode execute store check
  interrupt (fast enough)
• If interrupted-
• Save context (registers)
• Process interrupt
• Fetch data store

23
Interrupt Service Routine (similar to
subroutine or procedure in terms of what is
internally done)

• load PC with address of interrupt service routine
  
• save CPU state and etc.
• execute service routine
• return to the previous point and restore CPU
  state (the CPU may (semi) automatically save
  parts of the CPU state)   Note interrupt
  routines and CPU program designers are in many
  cases different, therefore, to be safe, all
  registers are saved when saving state in response
  to interrupts ... (i.e. do not know which
  registers are affected)

24
Issues

• How do you identify the module issuing the
  interrupt?
• How do you deal with multiple/simultaneous
  interrupts?
• i.e. an interrupt handler being interrupted

25
Arrival of interrupt

• It can be any time, but there are cases that the
  CPU does not want to or can not handle the
  interrupt (when ?)
• We need the capability to "enable" or "disable"
  incoming interrupts ...
• Interrupt Masking placing a user programmable
  interrupt mask register on interrupt request
  lines.   The interrupt request line is ANDed with
  contents of mask register ...
• More generally, we need the capability to
  selectively "enable" or "disable" certain (not
  just all) interrupts ...
• e.g. PRINT should interrupt CPU when CPU is ready
  only, so the CPU will disable the interrupt until
  it is ready to output something ...
• Incoming interrupts may be served based on
  priority or completely be ignored ...

26
Identifying who interrupts (1)

• Different hardware line for each module
• Limits number of devices
• Software poll
• CPU asks each module in turn (interrupt
  controller in the middle)
• Slow

27
Identifying who interrupts (2)

• Daisy Chain or Hardware poll
• Interrupt Acknowledge sent down a chain
• Module responsible places vector on bus
• CPU uses vector to identify handler routine
• Bus Master
• Module must claim the bus before it can raise
  interrupt
• e.g. PCI SCSI

28
Vectored interrupt

• Associate unique starting address with each line
  or send special code over I/O bus (so that single
  request line is used)
• This may be indirect (instead of using to code to
  figure out the service routine address, the
  address found by translating the code contains
  the service routine address)
• When CPU receives a interrupt request, it may be
  in the midst of processing an atomic instruction
  or serving high priority job, so it acknowledges
  that it is ready to serve ...

29
Figuring out Interrupt Service Address

• CPU gets the code or the vector
• then applies some simple function to map this to
  a number that contains the address of service
  routine.
• for example, in 8088, it can interface with 256
  devices, and handing addresses are stored in a
  table at the top of the memory from 0 to 1016
  (each entry needs 4 bytes).
• so we can think device i has code i
• if device 5 interrupts, it will send 5 as its
  vector, and we multiply it by 4
• address 20 will contain the address of service
  routine for device 5

30
Multiple Interrupts

• Each interrupt line has a priority
• Higher priority lines can interrupt lower
  priority lines

31
Interrupt Priorities (1)

• For instance, a timer must have very high
  priority so that the time is kept right ...
• If CPU polls on devices upon interrupt request,
  device that is polled first gets served first
• In a daisy chain where interrupt request
  acknowledge line is chained among devices (the
  acknowledge passes through the devices until
  reaching the first device requesting the
  interrupt).  The first device electrically close
  to the CPU gets served first ... (Closer the
  device is chained, the higher its priority
  priority)

32
Interrupt Priorities (2)

• A priority handling circuitry can be made to
  accept from multiple request lines (one request
  per device for example) and the priority handling
  circuit determines who to serve by sending the
  acknowledge signal to the device with highest
  priority.  This method is more flexible but
  requires more hardware
• And, of course, the daisy chain and priority
  handling circuitry can be mixed ... (several
  devices daisy chained for one priority group) ...

33
Interrupt during Interrupt (1)

• Ignore any interrupt during interrupt service,
  or
• Allow higher priority to be served
• Jump to higher priority interrupt service routine
  as usual
• Save information about any incoming lower
  priority interrupt requests in a stack as pending
  so that these can be served after the high
  priority ones are served

34
Interrupt during Interrupt (2)

• e.g. 3 devices printer (2), disk (4), serial
  device (5), numbers in bracket are prorities ...
  ------------------------------------------------
  ---------------------------------------- time
                                          
                                            
       A                       B        C     
  D          E                       F
• A printer interrupts and CPU starts serving it
• B serial device interrupts and since it has
  higher priority, printer service is stoppedand
  serial device is served
• C disk interrupts but since it has lower than
  currently running service routine, it pends
  (information saved on stack, or )
• D serial device service ends, returns to it
  jumped from the printer service routine, checks
  for any pending interrupt, finds disk is pending
  and since it has higher priority than printer,
  starts service it
• E disk service ends, printer service continues
• F printer service ends, returns to normal CPU
  execution

35
Exception

• Interrupts are generated internally by CPU)
• When ? ? Some undesirable CPU state (divide by
  zero, illegal memory access, etc)   like
  external events, they must be servied by
  interrupt routines
• Therefore, they too have vector numbers
  associated with types of exceptions which would
  be higher priority than user external interrupts,
  and their address table is located with the
  address table for the user external interrupts

36
Example - PC Bus

• 80x86 has one interrupt line
• 8086 based systems use one 8259A interrupt
  controller
• 8259A has 8 interrupt lines

37
Sequence of Events

• 8259A accepts interrupts
• 8259A determines priority
• 8259A signals 8086 (raises INTR line)
• CPU Acknowledges
• 8259A puts correct vector on data bus
• CPU processes interrupt

38
PC Interrupt Layout
8259A
8086
IRQ0
IRQ1
IRQ2
IRQ3
INTR
IRQ4
IRQ5
IRQ6
IRQ7
39
ISA Bus Interrupt System

• ISA bus chains two 8259As together
• Link is via interrupt 2
• Gives 15 lines
• 16 lines less one for link
• IRQ 9 is used to re-route anything trying to use
  IRQ 2
• Backwards compatibility
• Incorporated in chip set

40
ISA Interrupt Layout
(IRQ 2)
8259A
80x86
8259A
IRQ0
IRQ0 (8)
IRQ1
IRQ1 (9)
IRQ2
IRQ2 (10)
IRQ3
INTR
IRQ3 (11)
IRQ4
IRQ4 (12)
IRQ5
IRQ5 (13)
IRQ6
IRQ6 (14)
IRQ7
IRQ7 (15)
41
(No Transcript)
42
Figuring out Interrupt Service Address (2)

• 80286/386 does it similarly except the table can
  lie anywhere (not necessarily at the top of the
  memory).  The CPU gets 8 byte segment descriptors
  (to specify where the table is) and some code
  that basically offsets from the top of the table
  pointed by the segment descriptors ...
• Intel uses hardwired priority (a priority
  handling chip 8259 is used and high priority
  device must connect specific pins on this chip)

43
Figuring out Interrupt Service Address (3)

• 5 priority levels
• Reset
• Internal interrupts / Exceptions
• Software interrupts
• Nonmaskable interrupts
• External hardware interrupts
• Among same group, the machine checks for the type
  number (vector number) which numbers from 0 to
  255 (256 interrupts possible)
• For each vector, the starting address is stored
  at the top of the memory (memory location 0 to
  2554)
• For each vector, 4 bytes are needed, 2 for the
  segment address and 2 for the offset (IP)

44
(No Transcript)
45
(No Transcript)
46
(No Transcript)
47
Interrupt Control Instructions
48
(No Transcript)
49
(No Transcript)
50
(No Transcript)
51
(No Transcript)
52
(No Transcript)
53
(No Transcript)
54
(No Transcript)
55
(No Transcript)
56
(No Transcript)
57
Exceptional Control Flow

• Low level Mechanism
• exceptions
• change in control flow in response to a system
  event (i.e., change in system state)
• Combination of hardware and OS software
• Higher Level Mechanisms
• Process context switch
• Signals
• Nonlocal jumps (setjmp/longjmp)
• Implemented by either
• OS software (context switch and signals).
• C language runtime library nonlocal jumps.

58
System context for exceptions
Keyboard
Mouse
Printer
Modem
Processor
Interrupt controller
Serial port controller
Parallel port controller
Keyboard controller
Local/IO Bus
Network adapter
Video adapter
Memory
IDE disk controller
SCSI controller
SCSI bus
disk
Network
Display
disk
CDROM
59
Exceptions

• An exception is a transfer of control to the OS
  in response to some event (i.e., change in
  processor state)

User Process
OS
exception
current
event
exception processing by exception handler
next
exception return (optional)
60
Asynchronous Exceptions (Interrupts)

• Caused by events external to the processor
• Indicated by setting the processors interrupt
  pin
• handler returns to next instruction.
• Examples
• I/O interrupts
• hitting ctl-c at the keyboard
• arrival of a packet from a network
• arrival of a data sector from a disk
• Hard reset interrupt
• hitting the reset button
• Soft reset interrupt
• hitting ctl-alt-delete on a PC

61
Synchronous Exceptions

• Caused by events that occur as a result of
  executing an instruction
• Traps
• Intentional
• Examples system calls, breakpoint traps, special
  instructions
• Returns control to next instruction
• Faults
• Unintentional but possibly recoverable
• Examples page faults (recoverable), protection
  faults (unrecoverable).
• Either re-executes faulting (current)
  instruction or aborts.
• Aborts
• unintentional and unrecoverable
• Examples parity error, machine check.
• Aborts current program

62
Trap Example (system call)

• Opening a File
• User calls open(filename, options)
• Function open executes system call instruction
  int
• OS must find or create file, get it ready for
  reading or writing
• Returns integer file descriptor

0804d070 lt__libc_opengt . . . 804d082 cd 80
int 0x80 804d084 5b
pop ebx . . .
63
Trap Example
User Process
OS
exception
int
pop
return
Open file
64
Fault Example 1

• Memory Reference
• User writes to memory location
• That portion (page) of users memory is currently
  on disk
• Page handler must load page into physical memory
• Returns to faulting instruction
• Successful on second try

65
Fault Example 1
int a1000 main () a500 13
80483b7 c7 05 10 9d 04 08 0d movl
0xd,0x8049d10
66
Fault Example 2

• Memory Reference
• User writes to memory location
• Address is not valid
• Page handler detects invalid address
• Sends SIGSEG signal to user process
• User process exits with segmentation fault

67
Fault Example 2
int a1000 main () a5000 13
80483b7 c7 05 60 e3 04 08 0d movl
0xd,0x804e360
User Process
OS
page fault
event
movl
Detect invalid address
Signal process
68
Direct Memory Access

• Interrupt driven and programmed I/O require
  active CPU intervention
• Transfer rate is limited
• CPU is tied up
• DMA is the answer

69
DMA Function

• Additional Module (hardware) on bus
• DMA controller takes over from CPU for I/O

70
DMA Operation

• CPU tells DMA controller-
• Read/Write
• Device address
• Starting address of memory block for data
• Amount of data to be transferred
• CPU carries on with other work
• DMA controller deals with transfer
• DMA controller sends interrupt when finished

71
DMA TransferCycle Stealing

• DMA controller takes over bus for a cycle
• Transfer of one word of data
• Not an interrupt
• CPU does not switch context
• CPU suspended just before it accesses bus
• i.e. before an operand or data fetch or a data
  write
• Slows down CPU but not as much as CPU doing
  transfer

72
DMA Configurations (1)
DMA Controller
I/O Device
I/O Device
Main Memory
CPU

• Single Bus, Detached DMA controller
• Each transfer uses bus twice
• I/O to DMA then DMA to memory
• CPU is suspended twice

73
DMA Configurations (2)
DMA Controller
Main Memory
DMA Controller
CPU
I/O Device
I/O Device
I/O Device

• Single Bus, Integrated DMA controller
• Controller may support gt1 device
• Each transfer uses bus once
• DMA to memory
• CPU is suspended once

74
DMA Configurations (3)
DMA Controller
Main Memory
CPU
I/O Device
I/O Device
I/O Device
I/O Device

• Separate I/O Bus
• Bus supports all DMA enabled devices
• Each transfer uses bus once
• DMA to memory
• CPU is suspended once

75
I/O Channels

• I/O devices getting more sophisticated
• e.g. 3D graphics cards
• CPU instructs I/O controller to do transfer
• I/O controller does entire transfer
• Improves speed
• Takes load off CPU
• Dedicated processor is faster