Interrupts types and classification Interrupt driven os interrupt handling Generic routine, interrupt vectors, interrupt chaining Interrupt implementation in the system Interrupt controller priorities, masks, reentrancy Silberschatz, Operating System

• 
  Interrupts types and classification
  
• 
  Interrupt driven OS
  
• 
  Interrupt handling
  
  • 
    Generic routine, interrupt vectors, interrupt chaining
    
• 
  Interrupt implementation in the system
  
• 
  Interrupt controller
  
  • 
    priorities, masks, reentrancy
    

Chapter.13.2.2.

Interrupts, Traps, System Calls, Exceptions, Hardware Interrupts.

The 80x86 Instruction Set – Chapter 17.

The concept of an interrupt is something that has expanded in scope over the years.

The 80x86 family has only added to the confusion surrounding interrupts by introducing the int (software interrupt) instruction. This is system call named “interrupt”.
Indeed, different manufacturers have used terms like system calls, exceptions, faults, aborts, traps, and interrupts to describe the phenomena this chapter discusses. Unfortunately, there is no clear consensus as to the exact meaning of these terms. Different authors adopt different terms to their own use. While it is tempting to avoid the use of such misused terms altogether, for the purpose of discussion it would be nice to have a set of well defined terms we can use in this chapter. Therefore, we will pick four of the terms above, system calls, interrupts, traps, and exceptions, and define them. This chapter attempts to use the most common meanings for these terms, but don’t be surprised to find other texts using them in different contexts.

Terminology
Trap - Any kind of a control transfer to the OS

Interrupt – The mechanism of control transfer.

• 
  System call: Synchronous (planned), program-to-kernel transfer
  
  • 
    SYSCALL instruction in MIPS
    
  • 
    INT - on x86
    

• 
  Exception: Asynchronous, program-to-kernel transfer
  
  • 
    exceptional events:
    
  • 
    div by zero,
    
  • 
    page fault,
    
  • 
    page protection err,
    
  • 
    executing an illegal opcode …
    

• 
  Hardware Interrupt: Aysnchronous, device-initiated transfer
  
  • 
    network packet arrived
    
  • 
    keyboard event
    
  • 
    timer ticks
    
  • 
    mouse click
    
  • 
    information transfer finished (HDD, printer).
    

Software interrupts (directly called by program instruction)

CPU Internal hardware interrupts Caused by Software (the unexpected result of program instruction)

Hardware interrupts (caused by devices)

We will use the term System Call to denote a programmer initiated and expected transfer of control to a special handler routine. In many respects, a system call is nothing more than a specialized subroutine call. Many texts refer to system call as software interrupts.

The use of system calls helps us in the creation of programs. Using them our programs become shorter. It is easier to understand the programs and they usually have a better performance mostly due to their smaller size.

User Program running on the Computer

(OS service call)

• 
  Internal hardware interrupts as a result of user program instructions
  
• 
  An exception is an automatically generated system call (coerced rather than requested) that occurs in response to some exceptional condition.
  
• 
  Generally, there isn’t a specific instruction associated with an exception, instead, an exception occurs in response to some degenerate behavior of normal program execution.
  

Examples of conditions that may raise (cause) an exception include executing a division instruction with a zero divisor, executing an illegal opcode, and a memory protection fault. Whenever such a condition occurs, the CPU immediately suspends execution of the current instruction and transfers control to an exception handler routine. This routine can decide how to handle the exceptional condition; it can attempt to rectify the problem or abort the program and print an appropriate error message. Although you do not generally execute a specific instruction to cause an exception, as with the software interrupts (system calls), execution of some instruction is what causes an exception. For example, you only get a division error when executing a division instruction somewhere in a program.

The CPU interrupts the currently executing program, services the device, and then returns control back to the program.

If the interrupts are set then they have to be serviced by OS routines.

(Device Interrupt

Interrupt)s


User Program running on the Computer



Interrupt Servicing Routine of OS

The Current Program is interrupted

Out of CPU:

• 
  Keyboard
  
• 
  Mouse
  
• 
  Network Card
  
• 
  Timer
  
• 
  Printer
  
• 
  HDD
  
• 
  …
  

The interrupt-driven nature of an operating system defines that system's general structure. For each type of interrupt, separate segments of code in the operating system determine what action should be taken. An interrupt service routine is provided that is responsible for dealing with the interrupt.

HW Signals

Software Interrupts

• 
  The interrupt must transfer control to the appropriate interrupt service routine.
  
  • 
    The straightforward method for handling this transfer would be to invoke a generic routine to examine the interrupt information; the routine, in turn, would call the interrupt-specific handler.
    
  • 
    However, interrupts must be handled quickly, and, given that only a predefined number of interrupts is possible, a table of pointers to interrupt routines can be used instead. The interrupt routine is then called indirectly through the table, with no intermediate routine needed. Generally, the table of pointers is stored in low memory (the first 100 or so locations). These locations hold the addresses of the interrupt service routines for the various devices. This array, or interrupt vector, of addresses is then indexed by a unique device number, given with the interrupt request, to provide the address of the interrupt service routine for the interrupting device. Operating systems as different as MS-DOS and UNIX dispatch interrupts in this manner.
    
• 
  The interrupt architecture must also save the address of the interrupted instruction. Many old designs simply stored the interrupt address in a fixed location or in a location indexed by the device number. More recent architectures store the return address on the system stack. If the interrupt routine needs to modify the processor state-for instance, by modifying register values-it must explicitly save the current state and then restore that state before returning. After the interrupt is serviced, the saved return address is loaded into the program counter, and the interrupted computation resumes as though the interrupt had not occurred.