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



Download 182.84 Kb.
Page1/3
Date31.01.2017
Size182.84 Kb.
  1   2   3
Interrupts

  • 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 Concepts, 9th edition

Chapter.13.2.2.



Interrupts Types and classification

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




  • 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)




  • When the CPU is interrupted, it stops what it is doing and immediately transfers execution to a fixed location.

  • The fixed location usually contains the starting address where the service routine for the interrupt is located.

  • The interrupt service routine executes; on completion, the CPU resumes the interrupted computation.



User Program running on the Computer



Interrupt Service Routine of OS

The Current Program is interrupted






Interrupt is Serviced

User Program

Continues from the interrupted point


  • An interrupt service (handler) routine is a procedure written specifically to handle a system calls, exceptions, or interrupts.

  • Although different phenomenon cause system calls, exceptions, and interrupts, the structure of an interrupt service routine, or ISR (IHR), is approximately the same for each of these.



System Calls


  • a programmer initiated and expected transfer of control to a special handler routine ( particularly input/output)

  • In many respects, a system call is nothing more than a specialized subroutine call.

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 80x86 int instruction is the main vehicle for executing a system call. Note that system calls are usually unconditional; that is, when you execute an int instruction, control always transfers to the procedure associated with the system call. Since system calls execute via an explicit instruction, it is easy to determine exactly which instructions in a program will invoke a system call handling routine

System Calls can be directly activated by the assembler invoking the number of the desired interruption with the INT or SYSCALL or other system instructions.


  • Using system calls our programs become shorter

  • Easy to understand

  • Better performance due to short size

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.


This type of interruptions can be separated in two categories: the operating system OS system calls and the BIOS system calls.
The difference between the two is that the OS system calls are easier to use but they are slower since they are implemented using OS libraries.
On the other hand the BIOS system calls are much faster but they have the disadvantage that since they are part of the hardware, they are very basic and specific and can vary depending even on the brand of the maker of the hardware.
The election of the type of interruption to use will depend solely on the characteristics you want to give your program: speed, using the BIOS ones, or portability, using the ones from the OS.


OS system calls and BIOS system calls.

  • OS system calls

    • easier to use but they are slower since they are implemented using OS libraries

  • BIOS system calls

    • BIOS system calls are much faster

    • Since they are part of the hardware, they are very basic and specific. Programs are not portable.


User Program running on the Computer




System call or Software Interrupt

(OS service call)





System Call by user program itself

(INT, SYSCALL)

Interrupt Service Routine of OS

The Current Program is interrupted






System Call is Serviced

User Program

Continues from the interrupted point


Exceptions

  • 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.


Internal interrupts are generated by certain events which come during the execution of a program from the internal CPU hardware.

Exception

Internal Hardware Interrupt



  • caused by instruction

  • automatically generated by CPU




User Program running on the Computer





Computer


  • Overflow

  • Division by 0

  • page fault,

  • page protection err,

  • executing an illegal opcode

The Current Program is interrupted


Interrupt Service Routine (Exception Handler Routine)










Exception is Serviced (Cleared)

User Program

Continues from the interrupted point


External hardware interrupts


  • Hardware interrupts, the third category that we will refer to simply as interrupts, are program control interruption based on an external hardware event (external to the CPU).

  • These interrupts generally have nothing at all to do with the instructions currently executing;

  • instead, some event, such as pressing a key on the keyboard or a time out on a timer chip, informs the CPU that a device needs some attention.

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


An example of this type of interrupts is the Timer Interrupt. The timer makes the call to this interrupt several times during a second in order to allow the handling program to maintain the time and date.
External interrupts are generated by peripheral devices, such as keyboards, printers, communication cards, etc. They are also generated by coprocessors. It is not possible to deactivate external interrupts.

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



External Hardware Interrupt

(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












Interrupt is Serviced (Cleared)

User Program

Continues from the interrupted point


Interrupt driven Operating Systems

  • After booting when the kernel is loaded the operating system starts executing the first process, such as "init," and waits for some event to occur.

  • Modern operating systems are interrupt driven. If there are no processes to execute, no I/O devices to service, and no users to whom to respond, an operating system will sit quietly, waiting for something to happen.

  • The occurrence of an event is usually signaled by an interrupt

    • from either the hardware

    • or the software.


Hardware may trigger an interrupt at any time by sending a signal to the CPU, usually by way of the system bus.
Hardware Interrupt mechanism:


Separate segments of codes are needed for different interrupt services.

Different types of devices generate different types of interrupt signals corresponding to the different events happened on the devices.

This signal and then the interrupt is accompanied with the interrupt identifier that identifies the event and the desired kernel service.

When the interrupt occurs,



  • the interrupt hardware saves the state of the user code

  • switches to supervisor mode

  • and dispatches to the kernel routine that implements the requested service.


Software may trigger an interrupt by executing a special operation called a system call (also called a monitor call).
Usually, a program uses library calls to issue system calls. The library routines check the arguments given by the application, build a data structure to convey the arguments to the kernel, and then execute a special instruction called a Software Interrupt (system call). This instruction has an operand that identifies the desired kernel service. When a process executes the system call instruction, the interrupt hardware saves the state of the user code, switches to supervisor mode, and dispatches to the kernel routine that implements the requested service.
System Call mechanism:



Separate segments of codes are needed for different interrupt service.

Usually, a program issues system calls by special instructions called a Software Interrupt.

This instruction has an operand that identifies the desired kernel service.

When a process executes the trap instruction,



  • the interrupt hardware saves the state of the user code

  • switches to supervisor mode

  • and dispatches to the kernel routine that implements the requested service.

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.


Interrupt driven Operating Systems


HW Signals




Interrupts (Traps)


Hardware Interrupts



System Calls

Software Interrupts




Events

Serving Interrupts


Interrupt Vector Table

in Low Memory location

indexed by device numbers



Serving HW Interrupts

Serving SW Interrupts


Saving the current state in the stack


Serve Interrupt

Restore the saved state from the stack




Each computer design has its own interrupt mechanism, but several functions are common.


  • The interrupt must transfer control to the appropriate interrupt service routine.




  • The interrupt architecture must also save the address of the interrupted instruction and the state of the interrupted process.

    • More recent architectures store this information in the system stack




  • 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.



Interrupt handling
Interrupts are an important part of a computer architecture. Each computer design has its own interrupt mechanism, but several functions are common.

  • 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.




  • 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. In MIPS this routine is at 8000 0180 address.

    • Instead could be used the array or interrupt vector of addresses indexed by a unique device number to provide the address of the interrupt service routine for the interrupting device. In x86 architecture those vectors start from the 0000 0000 address.





Interrupt handling

(Generic Routine vs Interrupt Vectors Array)
The interrupt mechanism accepts an address - a number that selects a specific interrupt-handling routine from a small set. In most architectures, this address is an offset in a table called the interrupt vector. This vector contains the memory addresses of specialized interrupt handlers.


The interrupt handles the transfer of control to the appropriate interrupt service routine by

  • Generic Routine

  • Table of pointers – interrupt vector of addresses

Generic Routine Interrupt Vectors Array













Generic Routine to service Interrupts

Hardware analyzes the Interrupts and gives the appropriate READY addresses of routines.






Download 182.84 Kb.

Share with your friends:
  1   2   3




The database is protected by copyright ©ininet.org 2020
send message

    Main page