Computer-System Organization
Objectives
We would like to :
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
- 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.
- 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.