Computer-System Organization

Objectives

Notes

• This is 1.2
• ALL systems have at least one and possibly multiple CPUs
  • And each CPU may have one or more cores.
  • This is the place where code is executed
  • The OS needs to manage this.
• We are aware of additional devices
  • Disks
  • I/O (kbd, mouse, video card, ...)
  • Printers
  • Network devices
• These devices absolutely have their own Processor of some sort.
• These generally come with little "subroutines" called device drives.
  • This program is specific to
    • The os
    • The device
  • And it allows the os to control the device by calling the function.
• Most of the work is accomplished by the kernel writing to /reading from the device's memory.
• But how does this work
  • Let's go with an os initiated request.
    • This is probably initiated by another program.
  • The kernel calls the device driver routine needed to do the request
    • Again, this is a function, so it probably transfers data to the device via a bus (but this is really a write to memory operation)
    • And the driver either returns the requested information, and we are done.
    • Or the device start to process the request
    • In any case control returns to the kernel and operations continue.
  • Once the device completes the operation, it causes an interrupt to occur.
• Interrupts can occur from hardware or software
  • For example, the 6502 chip has two "interrupt lines"
    • A interrupt and a non-maskable interrupt
    • The CPU can ignore regular interrupts (mask them)
    • But it can not ignore non-maskable interrupts.
  • When these lines go from high to low, the processor is "informed" that an action needs to occur.
• Typically there is an interrupt handler
  • This is a routine in the kernel
  • When an interrupt occurs, the state of the process is saved
  • And this routine is called.
  • Which processes the interrupt
  • And returns to the executing process
• The terms are
  • Something raises an interrupt by putting a signal on the interrupt control line
  • The CPU catches the interrupt and dispatches the interrupt handler
  • The dispatch may be delayed or masked for critical sections of code
  • The handler services the interrupt then clears the interrupt
  • The handler returns to the kernel
• In modern hardware there is interrupt-controller hardware
  • This allows for prioritizing interrupts.
  • And handling multiple interrupts.
• Generally these contain interrupt vectors
  • A list of routines that get called when different interrupts occur
  • Along with a potential list of priorities.
• If you would like far more practical detail, Ben Eater's 6502 tutorial contain two videos where he builds an ISR for the 6502.
  • Basic Background.
  • Implementation
  • In the next video, he hooks up a keyboard!
  • Not required but cool.
• Since I have introduced the Arduino,
  • There is a command in the language to implement interrupts.
  • attachInterrupt.
  • You can select a pin to serve as the interrupt pin
    • Only supported on a select set of pins.
    • For the nano I belive D2 and D3
  • You select a ISR or interrupt service routine
    • void and takes no parameters
    • "Generally, an ISR should be as short and fast as possible. "
    • There is a restriction on what functions can be called
  • You can select a mode
    • On low, change, rising or falling
• There are a built in set of interrupts in the runtime system
  • See this page.
  • They are needed for task completion of operations or notification that an operation is complete.
• Hopefully there will be a demo here.