MESSAGE
| DATE | 2015-01-29 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [LIU Comp Sci] Operating System Interupts
|
From owner-learn-outgoing-at-mrbrklyn.com Thu Jan 29 22:11:15 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id A78F21612E4; Thu, 29 Jan 2015 22:11:15 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 954EA1612E7; Thu, 29 Jan 2015 22:11:15 -0500 (EST)
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 192EA1612E4
for ; Thu, 29 Jan 2015 22:11:15 -0500 (EST)
Received: from [10.0.0.19] (unknown [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id EDB9813B8A;
Thu, 29 Jan 2015 22:11:14 -0500 (EST)
Message-ID: <54CAF652.5050609-at-panix.com>
Date: Thu, 29 Jan 2015 22:11:14 -0500
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: learn-at-nylxs.com, Samir Iabbassen
Subject: Re: [LIU Comp Sci] Operating System Interupts
References: <54CAAE57.1030900-at-panix.com>
In-Reply-To: <54CAAE57.1030900-at-panix.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
This is the last one and these are in usenet at
comp.os.linux.hardware
Your all welcome to jump in and ask a question on usenet or pose an
answer or a correction.
By all means, let us not all sit on our asses like we are students (yes
that is cynicism and a complaint)
There are lots of resources out there to get involved and to learn.
Learning is what we are supposed to be doing...
Learning requires conversation, integration and discussion of knowledge...
sigh
Joe Pfeiffer writes:
> ruben safir writes:
>
>> I'm wondering if anyone has a background in operating system design.
>> I'm taking a class is OS's and the text is
>>
>> OPERATING
>> SYSTEM
>> CONCEPTS
>> ABRAHAM SILBERSCHATZ
>> 9th edition, and it says something that is puzzling me
>>
>>
>>
>> "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"
>>
>> " Since only a predefined number of interrupts is possible, a table of
>> pointers to interrupt routines can be used instead*** to provide the
>> necessary speed. The interrupt routine is called indirectly through the
>> table, with no intermediate routine needed. Generally, the table of
>> pointers is stored in low memory (the first hundred 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 Windows and
>> UNIX dispatch interrupts in this manner."
>>
>>
>> *** Instead of what? Just because you have a table of pointers to
>> routines doesn't change the need for a routine, a generic routine
>> perhaps, from accessing that table.
>
> In an interrupt vector table like he's describing, the hardware indexes
> the table directly and jumps straight to the ISR without any software
> intervention before it gets there.
After reading some of the other responses, I'll give a concrete example
(which sounds like the machine he has in mind): the interrupt mechanism
on the old DEC PDP-11.
On the PDP-11, a device requested an interrupt by asserting a bus
request line. The CPU would respond by asserting a corresponding bus
grant line (there was a mechanism for resolving multiple simultaneous
interrupt requests, which is not relevant here).
After receiving the bus grant, the device would place a memory address
on the bus address lines. This was the address of the device's
"interrupt vector".
The CPU would retrieve a new program counter (PC) and processor status
word (PSW) from the four bytes at this address, push the old PC and PSW
on the stack, and begin execution at the new PC.
|
|
