MESSAGE
| DATE | 2015-02-10 |
| FROM | Ruben
|
| SUBJECT | Subject: [LIU Comp Sci] Fwd: operating systems design
|
From owner-learn-outgoing-at-mrbrklyn.com Tue Feb 10 08:48:41 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 376891612E7; Tue, 10 Feb 2015 08:48:41 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 1F8101612EB; Tue, 10 Feb 2015 08:48:41 -0500 (EST)
Delivered-To: learn-at-nylxs.com
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174])
by mrbrklyn.com (Postfix) with ESMTP id 59C371612E7
for ; Tue, 10 Feb 2015 08:48:38 -0500 (EST)
Received: by mail-vc0-f174.google.com with SMTP id id10so1019029vcb.5
for ; Tue, 10 Feb 2015 05:48:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type;
bh=QgVnlYCH/WXI/WTEM+dpEu4TesLtvMFmBjPch+980AA=;
b=lH0lCGaTcQ4VmO2GMcf2cOcMBCBqHPPvugkVBssBQ76lJ9Hk3tljTgv110o3KDk2KV
uRsMBdAU4qIFocgU9nVjcQQNgylXagD1/BdytRlxViPmT4Vj5/ZV/mZhn9rlajb4HJKY
ntujEdK6bSB7tHe8wZHW7zjR2BLS/c8q+BL5LD58zgXB954xqtBYv2KLTk0FHDF7SKph
B37kVCQQ9am0OpVVMSJDrEq/iHgnXP8nnbmkq26p6SZPWMUIVjDtKozMgcCM2Bcxc3iO
rS1zXabF9ccglqyrjrMXhOs0Gje4DVY4Af2qmAhi+BG+IutnV+5ChmNRQIkV4lt0W2ie
r2ag==
X-Gm-Message-State: ALoCoQnnevXq0hMkJWjRBKStDW4IowxwluwjUJ5YxilqzBWDY9kN3IoRfp1Eni+dcKF/st5mWZ+J
X-Received: by 10.221.66.77 with SMTP id xp13mr14005735vcb.32.1423576118405;
Tue, 10 Feb 2015 05:48:38 -0800 (PST)
Received: from [10.0.0.19] ([96.57.23.82])
by mx.google.com with ESMTPSA id qz4sm944886vdb.11.2015.02.10.05.48.37
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 10 Feb 2015 05:48:37 -0800 (PST)
Message-ID: <54DA0C34.8010206-at-my.liu.edu>
Date: Tue, 10 Feb 2015 08:48:36 -0500
From: Ruben
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
Subject: [LIU Comp Sci] Fwd: operating systems design
References:
In-Reply-To:
X-Forwarded-Message-Id:
Content-Type: multipart/mixed;
boundary="------------070209080102000900040602"
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
This is a multi-part message in MIME format.
--------------070209080102000900040602
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Attached in the thread on Operating System Interupts.
The issue initially, for me, was understanding how interrupts happen
without "calling a routine" as was professed in the text, and then how
the interrupt vector was stored and invoked. This is the core of
operating systems interrupt technology and I just don't really
understand it. But it has spurred an excellent conversation on usenet
which I attach and would ask you to read for your own education.
This is from comp.os.linux.misc
Ruben
--------------070209080102000900040602
Content-Type: message/rfc822;
name="operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="operating systems design.eml"
Path: reader1.panix.com!panix!not-for-mail
From: ruben safir
Newsgroups: comp.os.linux.misc
Subject: operating systems design
Date: Thu, 29 Jan 2015 17:11:35 -0500
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID:
NNTP-Posting-Host: 96.57.23.82
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Trace: reader1.panix.com 1422569496 29417 96.57.23.82 (29 Jan 2015 22:11:36 GMT)
X-Complaints-To: abuse-at-panix.com
NNTP-Posting-Date: Thu, 29 Jan 2015 22:11:36 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
Xref: panix comp.os.linux.misc:813928
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.
Ruben
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Rich
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Thu, 29 Jan 2015 22:29:01 +0000 (UTC)
Organization: My Linux Box
Message-ID:
References:
Injection-Date: Thu, 29 Jan 2015 22:29:01 +0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="fb6a430d69791831a55ece50eef4a37e";
logging-data="1232"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX19UumSd6yjNpjFgLVc+pNcS"
User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (Linux/2.4.31 (i686))
Cancel-Lock: sha1:5y4W6CwCpw5f4c8H4pUkfiKHzsE=
Xref: panix comp.os.linux.misc:813929
ruben safir wrote:
> 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.
Instead of what was described in the first paragraph you quoted.
The first paragraph is stating that the simplest method is to have all
interrupts call into a common routine. Then that common routine has to
figure out what called it, and perform the appropriate action
(typically done by making another call into the actual subroutine that
handles the specifics).
The "instead" in the second paragraph is removing the "generic, long
list of 'if this then that'" tests which would make up the single
generic routine, and instead replacing it with each "thing" which
generates an interrupt telling the CPU: I am number X. Then, knowing
number X made the request, the cpu can directly call the specific
subroutine necessary to handle the specifics. No "middle man"
necessary.
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!not-for-mail
From: ruben safir
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Fri, 30 Jan 2015 08:19:33 -0500
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID:
References:
NNTP-Posting-Host: 96.57.23.82
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Trace: reader1.panix.com 1422623973 2827 96.57.23.82 (30 Jan 2015 13:19:33 GMT)
X-Complaints-To: abuse-at-panix.com
NNTP-Posting-Date: Fri, 30 Jan 2015 13:19:33 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
In-Reply-To:
Xref: panix comp.os.linux.misc:813931
On 01/29/2015 05:29 PM, Rich wrote:
> ruben safir wrote:
>> 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.
>
> Instead of what was described in the first paragraph you quoted.
>
> The first paragraph is stating that the simplest method is to have all
> interrupts call into a common routine. Then that common routine has to
> figure out what called it, and perform the appropriate action
> (typically done by making another call into the actual subroutine that
> handles the specifics).
>
> The "instead" in the second paragraph is removing the "generic, long
> list of 'if this then that'" tests which would make up the single
> generic routine, and instead replacing it with each "thing" which
> generates an interrupt telling the CPU: I am number X. Then, knowing
> number X made the request, the cpu can directly call the specific
> subroutine necessary to handle the specifics. No "middle man"
> necessary.
>
Thank you. I'm very ignorant about these things, so please pardon me if
I ask a follow up question with this regard. I took an architecture
place last semester, and other than that, and my 20 some odd years of
tinkering, I don't have much of formal education as to how this works.
The objective is to remove a routine that has a cascade of ifelses,
which is fine. And you don't want the CPU to run a routine to figure
out who is call it. How can the CPU know who calls it anyway, with or
without a routine? It is only but getting specific information
transmitted to it on a line bus as an opcode that it can respond to an
instruction. So if an interupt device sends a signal, the signal has to
identify who it is, regardless. This is not something the hardware can
conjure up by itself. And even an array of HW numbers in vector doesn't
prevent the need from having to search the array for the correct
hardware device interrupt routine to search for. Additionally, you have
to make a back up of the current state, so that takes some routine code.
So how is it possible to eliminate that "middle man"? No matter how the
interrupt routines are mapped as data in a system, you still need a
routine to process the requests? How can it be eliminated?
Ruben
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "David W. Hodgins"
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Fri, 30 Jan 2015 09:01:15 -0500
Organization: A noiseless patient Spider
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 8bit
Injection-Info: mx02.eternal-september.org; posting-host="c2db21edd2dc0bb0525dd696e00a6047";
logging-data="16903"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX1+eaD8PLFiBiH2Z4vA28oOOLIUDqZ4OcxA="
User-Agent: Opera Mail/12.16 (Linux)
Cancel-Lock: sha1:rscdT+ZsIJvuXS6frms0cVyVisM=
Xref: panix comp.os.linux.misc:813932
On Fri, 30 Jan 2015 08:19:33 -0500, ruben safir wrote:
> Thank you. I'm very ignorant about these things, so please pardon me if
> I ask a follow up question with this regard. I took an architecture
> place last semester, and other than that, and my 20 some odd years of
> tinkering, I don't have much of formal education as to how this works.
Run a google search on 'wiki interrupt', then read the first page.
> So how is it possible to eliminate that "middle man"? No matter how the
> interrupt routines are mapped as data in a system, you still need a
> routine to process the requests? How can it be eliminated?
The only middle man is the kernel, which just calls the appropriate
code from the bios. Interrupt requests can come from hardware, or
from software. The processor just executes the appropriate code from
the bios.
Another good website to skim, is
http://en.wikipedia.org/wiki/Ralf_Brown%27s_Interrupt_List
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!bloom-beacon.mit.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!ottix-news.ottix.net!Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 30 Jan 2015 08:07:19 -0600
From: Robert Heller
Organization: Deepwoods Software
X-Newsreader: TkNews 3.0 (1.0.18.4)
Subject: Re: operating systems design
In-Reply-To:
References:
Newsgroups: comp.os.linux.misc
Originator: heller-at-sharky2.deepsoft.com
Message-ID:
Date: Fri, 30 Jan 2015 08:07:19 -0600
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-lBdkGqetcw5eyY4ze+DTJpOwHS2u9SgUxIB6Q5esNv5kcGJ/2W71YjtJCZd8qq9ufowDTyBOUDJE4XK!1ycX8LgRNddhVAAqu5IWzwr/G/4Uq0ARmbBiNvsqO07r/w/EFyURzMMkbIEY9SqAN5NU28eBnxw=
X-Complaints-To: abuse-at-giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6912
Xref: panix comp.os.linux.misc:813933
At Fri, 30 Jan 2015 08:19:33 -0500 ruben safir wrote:
>
> On 01/29/2015 05:29 PM, Rich wrote:
> > ruben safir wrote:
> >> 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.
> >
> > Instead of what was described in the first paragraph you quoted.
> >
> > The first paragraph is stating that the simplest method is to have all
> > interrupts call into a common routine. Then that common routine has to
> > figure out what called it, and perform the appropriate action
> > (typically done by making another call into the actual subroutine that
> > handles the specifics).
> >
> > The "instead" in the second paragraph is removing the "generic, long
> > list of 'if this then that'" tests which would make up the single
> > generic routine, and instead replacing it with each "thing" which
> > generates an interrupt telling the CPU: I am number X. Then, knowing
> > number X made the request, the cpu can directly call the specific
> > subroutine necessary to handle the specifics. No "middle man"
> > necessary.
> >
>
>
> Thank you. I'm very ignorant about these things, so please pardon me if
> I ask a follow up question with this regard. I took an architecture
> place last semester, and other than that, and my 20 some odd years of
> tinkering, I don't have much of formal education as to how this works.
>
> The objective is to remove a routine that has a cascade of ifelses,
> which is fine. And you don't want the CPU to run a routine to figure
> out who is call it. How can the CPU know who calls it anyway, with or
> without a routine? It is only but getting specific information
> transmitted to it on a line bus as an opcode that it can respond to an
> instruction. So if an interupt device sends a signal, the signal has to
> identify who it is, regardless. This is not something the hardware can
> conjure up by itself. And even an array of HW numbers in vector doesn't
> prevent the need from having to search the array for the correct
> hardware device interrupt routine to search for. Additionally, you have
> to make a back up of the current state, so that takes some routine code.
>
> So how is it possible to eliminate that "middle man"? No matter how the
> interrupt routines are mapped as data in a system, you still need a
> routine to process the requests? How can it be eliminated?
'Modern' processors use some sort of 'Interupt Controller' chip (included in
the motherboard chipset logic on a typical x86/x86_64 computer system).
Typically devices don't just directly 'yank' on the 'Int' pin of the CPU, they
'yank' on one the (many) pins on the 'Interupt Controller' chip. The 'Interupt
Controller' chip then 'yanks' on the CPU's 'Int' pin. The CPU then goes into a
bus read cycle and the 'Interupt Controller' chip presents a value based on
which pin the device yanked on to the data bus, which the CPU reads as part of
its interupt processing cycle. This value is used to index into the interupt
vector table. Think of the 'Interupt Controller' as a butler. The butler
answers the door, finds out who is there, possibly getting a card or some
other identifying object, and then fetches the master and lets him know a
partitular someone is at the door. And if the person at the door is not
worth the master's time, the butler sends the person on his way -- the
'Interupt Controller' gives each device a priority and if the current priority
is higher than the device in question, its interupt is ignored (discarded) and
the CPU never sees it.
Esentually, the "middle man" has been replaced with a cheap piece of hardware.
See: https://en.wikipedia.org/wiki/Programmable_Interrupt_Controller
>
>
> Ruben
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller-at-deepsoft.com -- Webhosting Services
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail
From: Jeroen Belleman
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Fri, 30 Jan 2015 15:43:18 +0100
Organization: Aioe.org NNTP Server
Message-ID:
References:
NNTP-Posting-Host: 4cdPr1/B+K+ySMbee62eSQ.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse-at-aioe.org
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130918 Thunderbird/17.0.9
X-Notice: Filtered by postfilter v. 0.8.2
Xref: panix comp.os.linux.misc:813934
On 2015-01-30 15:07, Robert Heller wrote:
> At Fri, 30 Jan 2015 08:19:33 -0500 ruben safir wrote:
>
>>
>> On 01/29/2015 05:29 PM, Rich wrote:
>>> ruben safir wrote:
>>>> 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. [...]
> 'Interupt Controller' gives each device a priority and if the current priority
> is higher than the device in question, its interupt is ignored (discarded) and
> the CPU never sees it.
>
Now that would lead to chaos. Lower priority interrupts are
not just discarded. They are served after higher priority
interrupts have been dealt with.
Jeroen Belleman
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!bloom-beacon.mit.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!ottix-news.ottix.net!Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 30 Jan 2015 09:09:28 -0600
From: Robert Heller
Organization: Deepwoods Software
X-Newsreader: TkNews 3.0 (1.0.18.4)
Subject: Re: operating systems design
In-Reply-To:
References:
Newsgroups: comp.os.linux.misc
Originator: heller-at-sharky2.deepsoft.com
Message-ID:
Date: Fri, 30 Jan 2015 09:09:28 -0600
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-7tC94bqswkZOt5zPB4Cu9hdUdOtJQMi/3m/7LH7KbFpG+pg873l3iObwOu26rKLhZJQWZJfkUkhGb6e!FUDU7EXvwv8B1omkc1NUfdck7/MpSZHh8y7KYN8oTEdLCuaue/H9Inu+wRESJdtaFSgJycY4bJg=
X-Complaints-To: abuse-at-giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2877
Xref: panix comp.os.linux.misc:813935
At Fri, 30 Jan 2015 15:43:18 +0100 Jeroen Belleman wrote:
>
> On 2015-01-30 15:07, Robert Heller wrote:
> > At Fri, 30 Jan 2015 08:19:33 -0500 ruben safir wrote:
> >
> >>
> >> On 01/29/2015 05:29 PM, Rich wrote:
> >>> ruben safir wrote:
> >>>> 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. [...]
>
> > 'Interupt Controller' gives each device a priority and if the current priority
> > is higher than the device in question, its interupt is ignored (discarded) and
> > the CPU never sees it.
> >
>
> Now that would lead to chaos. Lower priority interrupts are
> not just discarded. They are served after higher priority
> interrupts have been dealt with.
It actually depends on the Interupt Controller and how it is configured. In
some cases, the device can queue up data and can be polled later (and such
devices will keep sending interrupts until it is serviced).
>
> Jeroen Belleman
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller-at-deepsoft.com -- Webhosting Services
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Rich
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Fri, 30 Jan 2015 15:21:44 +0000 (UTC)
Organization: My Linux Box
Message-ID:
References:
Injection-Date: Fri, 30 Jan 2015 15:21:44 +0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="fb6a430d69791831a55ece50eef4a37e";
logging-data="14411"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX19CfHON9UBYuxiaANA91fYj"
User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (Linux/2.4.31 (i686))
Cancel-Lock: sha1:G3rXvOrJ7Gzn988uO0lhoOdAk/Q=
Xref: panix comp.os.linux.misc:813936
ruben safir wrote:
> On 01/29/2015 05:29 PM, Rich wrote:
> > ruben safir wrote:
> >> 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.
> >
> > Instead of what was described in the first paragraph you quoted.
> >
> > The first paragraph is stating that the simplest method is to have all
> > interrupts call into a common routine. Then that common routine has to
> > figure out what called it, and perform the appropriate action
> > (typically done by making another call into the actual subroutine that
> > handles the specifics).
> >
> > The "instead" in the second paragraph is removing the "generic, long
> > list of 'if this then that'" tests which would make up the single
> > generic routine, and instead replacing it with each "thing" which
> > generates an interrupt telling the CPU: I am number X. Then, knowing
> > number X made the request, the cpu can directly call the specific
> > subroutine necessary to handle the specifics. No "middle man"
> > necessary.
> ...
> The objective is to remove a routine that has a cascade of ifelses,
> which is fine. And you don't want the CPU to run a routine to figure
> out who is call it. How can the CPU know who calls it anyway, with
> or without a routine?
Because part of the hardware bus cycling that occurs due to the
interrupt pin being triggered is for the express purpose of having the
device causing the interrupt send its identification to the CPU.
> It is only but getting specific information transmitted to it on a
> line bus as an opcode that it can respond to an instruction.
The initial handling of the bus cycles for an interrupt do not utilize
the normal instruction opcode processing system that normal program code
goes through (note, there are exceptions to this, but generally this is
true)
> So if an interupt device sends a signal, the signal has to identify
> who it is, regardless.
That is exactly how it works. The device says "I need assistance", the
bus cycles generated by the CPU in response ask "Who are you?" and the
device responds with "I am number X".
> This is not something the hardware can conjure up by itself.
No, some hardware designer either hardwired an identification number,
or during hardware initialization an identification number was
assigned, and stored by the device.
> And even an array of HW numbers in vector doesn't prevent the need
> from having to search the array for the correct hardware device
> interrupt routine to search for.
Yes it does. There's no search. The identification numbers are
integers that start at zero. Each address pointer in the array is a
fixed size. So the correct pointer to use is a simple multiplication.
sizeof(interrupt_routine_pointer) * identification number. Add that to
the starting address of the table and you have the proper address of
the slot containing the pointer you are looking for. And both this
multiplication and addition are typically performed by dedicated
hardware within the cpu, rather than by running instructions (note,
always expections, but generally true).
> Additionally, you have to make a back up of the current state, so
> that takes some routine code.
Yes, but whether 'code' is involved depends upon the particular CPU.
Some CPU's have special hardware dedicated to performing the state
backup operation, so zero code has to be run. Others simply save the
minimum possible to return to the current address and leave it up to
the interrupt service routine code to perform the actual state save.
Others fall somewhere in the middle.
> So how is it possible to eliminate that "middle man"? No matter how the
> interrupt routines are mapped as data in a system, you still need a
> routine to process the requests? How can it be eliminated?
You've not eliminated the routine that actually handles the request.
That is always needed. You've eliminated the middle man that has to
decide which handler routine is the correct handler routine to execute.
Most (modern) CPU's provide a large number of possible routines (Intel
x86 allows up to 256 different possible interrupt routines to be setup,
note that most 'systems' don't actually use all of this offered by the
CPU).
Imagine the time difference to run code to decide which one out of 256
possible routines to select, vs. simply having the hardware device tell
the CPU to "run routine number 187".
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!usenet.stanford.edu!news.glorb.com!Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 30 Jan 2015 11:27:07 -0600
From: Robert Heller
Organization: Deepwoods Software
X-Newsreader: TkNews 3.0 (1.0.18.4)
Subject: Re: operating systems design
In-Reply-To:
References:
Newsgroups: comp.os.linux.misc
Originator: heller-at-sharky2.deepsoft.com
Message-ID:
Date: Fri, 30 Jan 2015 11:27:07 -0600
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Bc1sIh0q7s0CYWlxTE64Xg5tnI3H8gLe7xLUJieimV8BRi7dqoc4P6Uhtvx1CwzBJPR+qyhG2Tln269!gmRPamCHIRjg4jlqHbO9KE/wIgTeS5lhjznDnEyjyYrVMoEHcB+AVgpYJpcumi3J2TWlP7HX97k=
X-Complaints-To: abuse-at-giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8353
Xref: panix comp.os.linux.misc:813937
At Fri, 30 Jan 2015 15:21:44 +0000 (UTC) Rich wrote:
>
> ruben safir wrote:
> > On 01/29/2015 05:29 PM, Rich wrote:
> > > ruben safir wrote:
> > >> 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.
> > >
> > > Instead of what was described in the first paragraph you quoted.
> > >
> > > The first paragraph is stating that the simplest method is to have all
> > > interrupts call into a common routine. Then that common routine has to
> > > figure out what called it, and perform the appropriate action
> > > (typically done by making another call into the actual subroutine that
> > > handles the specifics).
> > >
> > > The "instead" in the second paragraph is removing the "generic, long
> > > list of 'if this then that'" tests which would make up the single
> > > generic routine, and instead replacing it with each "thing" which
> > > generates an interrupt telling the CPU: I am number X. Then, knowing
> > > number X made the request, the cpu can directly call the specific
> > > subroutine necessary to handle the specifics. No "middle man"
> > > necessary.
>
> > ...
>
> > The objective is to remove a routine that has a cascade of ifelses,
> > which is fine. And you don't want the CPU to run a routine to figure
> > out who is call it. How can the CPU know who calls it anyway, with
> > or without a routine?
>
> Because part of the hardware bus cycling that occurs due to the
> interrupt pin being triggered is for the express purpose of having the
> device causing the interrupt send its identification to the CPU.
>
> > It is only but getting specific information transmitted to it on a
> > line bus as an opcode that it can respond to an instruction.
>
> The initial handling of the bus cycles for an interrupt do not utilize
> the normal instruction opcode processing system that normal program code
> goes through (note, there are exceptions to this, but generally this is
> true)
>
> > So if an interupt device sends a signal, the signal has to identify
> > who it is, regardless.
>
> That is exactly how it works. The device says "I need assistance", the
> bus cycles generated by the CPU in response ask "Who are you?" and the
> device responds with "I am number X".
This is usually done with the help of an Interupt Controller in the
motherboard logic.
>
> > This is not something the hardware can conjure up by itself.
>
> No, some hardware designer either hardwired an identification number,
> or during hardware initialization an identification number was
> assigned, and stored by the device.
>
> > And even an array of HW numbers in vector doesn't prevent the need
> > from having to search the array for the correct hardware device
> > interrupt routine to search for.
>
> Yes it does. There's no search. The identification numbers are
> integers that start at zero. Each address pointer in the array is a
> fixed size. So the correct pointer to use is a simple multiplication.
> sizeof(interrupt_routine_pointer) * identification number. Add that to
> the starting address of the table and you have the proper address of
> the slot containing the pointer you are looking for. And both this
> multiplication and addition are typically performed by dedicated
> hardware within the cpu, rather than by running instructions (note,
> always expections, but generally true).
Actually, the pointers are always a power of 2 in size, so the
'multiplication' is implemented as a shift (or really just wired to be n-bits
left of the 0'th bit -- no real ALU cycles are used, except for an pointer
offset computation.
>
> > Additionally, you have to make a back up of the current state, so
> > that takes some routine code.
>
> Yes, but whether 'code' is involved depends upon the particular CPU.
> Some CPU's have special hardware dedicated to performing the state
> backup operation, so zero code has to be run. Others simply save the
> minimum possible to return to the current address and leave it up to
> the interrupt service routine code to perform the actual state save.
> Others fall somewhere in the middle.
>
> > So how is it possible to eliminate that "middle man"? No matter how the
> > interrupt routines are mapped as data in a system, you still need a
> > routine to process the requests? How can it be eliminated?
>
> You've not eliminated the routine that actually handles the request.
> That is always needed. You've eliminated the middle man that has to
> decide which handler routine is the correct handler routine to execute.
> Most (modern) CPU's provide a large number of possible routines (Intel
> x86 allows up to 256 different possible interrupt routines to be setup,
> note that most 'systems' don't actually use all of this offered by the
> CPU).
>
> Imagine the time difference to run code to decide which one out of 256
> possible routines to select, vs. simply having the hardware device tell
> the CPU to "run routine number 187".
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller-at-deepsoft.com -- Webhosting Services
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Rich
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Fri, 30 Jan 2015 19:10:01 +0000 (UTC)
Organization: My Linux Box
Message-ID:
References:
Injection-Date: Fri, 30 Jan 2015 19:10:01 +0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="fb6a430d69791831a55ece50eef4a37e";
logging-data="9094"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX18yFk2o+79SrijXIKLwxNnO"
User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (Linux/2.4.31 (i686))
Cancel-Lock: sha1:pT24UKwa3dFYLAQJ9IQkc0d8Drc=
Xref: panix comp.os.linux.misc:813938
Robert Heller wrote:
> At Fri, 30 Jan 2015 15:21:44 +0000 (UTC) Rich wrote:
> > ruben safir wrote:
> > > So if an interupt device sends a signal, the signal has to identify
> > > who it is, regardless.
> >
> > That is exactly how it works. The device says "I need assistance", the
> > bus cycles generated by the CPU in response ask "Who are you?" and the
> > device responds with "I am number X".
> This is usually done with the help of an Interupt Controller in the
> motherboard logic.
True, on more modern systems. On older CPU's, if they had it at all,
it was built in (and not nearly as powerful).
> > > And even an array of HW numbers in vector doesn't prevent the
> > > need from having to search the array for the correct hardware
> > > device interrupt routine to search for.
> >
> > Yes it does. There's no search. The identification numbers are
> > integers that start at zero. Each address pointer in the array is
> > a fixed size. So the correct pointer to use is a simple
> > multiplication. sizeof(interrupt_routine_pointer) * identification
> > number. Add that to the starting address of the table and you have
> > the proper address of the slot containing the pointer you are
> > looking for. And both this multiplication and addition are
> > typically performed by dedicated hardware within the cpu, rather
> > than by running instructions (note, always expections, but
> > generally true).
> Actually, the pointers are always a power of 2 in size, so the
> 'multiplication' is implemented as a shift (or really just wired to
> be n-bits left of the 0'th bit -- no real ALU cycles are used, except
> for an pointer offset computation.
Also true, I left out those details to try not to confuse him with
too much information. I presumed he knew how to multiply and add.
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
X-Received: by 10.182.107.202 with SMTP id he10mr17221032obb.19.1422883806333;
Mon, 02 Feb 2015 05:30:06 -0800 (PST)
Path: reader1.panix.com!panix!usenet.stanford.edu!hl2no5630735igb.0!news-out.google.com!db6ni16349igc.0!nntp.google.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!spln!extra.newsguy.com!newsp.newsguy.com!news4
From: Jean-David Beyer
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Mon, 02 Feb 2015 08:29:51 -0500
Organization: NewsGuy - Unlimited Usenet $23.95
Message-ID:
References:
NNTP-Posting-Host: pd3e81aab4985133a536063386a6725c24568245f1eefffbc.newsdawg.com
Mime-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120829 Thunderbird/10.0.7
In-Reply-To:
X-Enigmail-Version: 1.4
X-Received-Bytes: 2453
X-Received-Body-CRC: 1749764593
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Xref: panix comp.os.linux.misc:813965
On 01/30/2015 02:10 PM, Rich wrote:
> Robert Heller wrote:
>> At Fri, 30 Jan 2015 15:21:44 +0000 (UTC) Rich wrote:
>>> ruben safir wrote:
>>>> So if an interupt device sends a signal, the signal has to identify
>>>> who it is, regardless.
>>>
>>> That is exactly how it works. The device says "I need assistance", the
>>> bus cycles generated by the CPU in response ask "Who are you?" and the
>>> device responds with "I am number X".
>
>> This is usually done with the help of an Interupt Controller in the
>> motherboard logic.
>
> True, on more modern systems. On older CPU's, if they had it at all,
> it was built in (and not nearly as powerful).
>
I guess it depends on what you consider to be a modern system.
The interrupts of an IBM 704 (vacuum tube, 1950s era) worked just this
way. And all IBM's 70** series machines did too.
So also did the GE 625, 635, and 645 machines.
Also the mini-computers by DEC and Computer Control Corporation .
And Honeywell.
I cannot remember what the Control Data and Burroughs machines did.
I would not call any of those "modern". They all had a "transfer vector
table in the bottom addresses of hardware RAM.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key:166D840A 0C610C8B Registered Machine 1935521.
/( )\ Shrewsbury, New Jersey http://linuxcounter.net
^^-^^ 08:25:01 up 10 days, 16:46, 2 users, load average: 4.47, 4.45, 4.57
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Rich
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Mon, 2 Feb 2015 15:09:23 +0000 (UTC)
Organization: My Linux Box
Message-ID:
References:
Injection-Date: Mon, 2 Feb 2015 15:09:23 +0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="fb6a430d69791831a55ece50eef4a37e";
logging-data="26792"; mail-complaints-to="abuse-at-eternal-september.org"; posting-account="U2FsdGVkX19yuomhwJE5dWpVabqHl1Et"
User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (Linux/2.4.31 (i686))
Cancel-Lock: sha1:rNzrE1aO7wqyAqVcAmGxEF+84ic=
Xref: panix comp.os.linux.misc:813966
Jean-David Beyer wrote:
> On 01/30/2015 02:10 PM, Rich wrote:
> > Robert Heller wrote:
> >> At Fri, 30 Jan 2015 15:21:44 +0000 (UTC) Rich wrote:
> >>> ruben safir wrote:
> >>>> So if an interupt device sends a signal, the signal has to identify
> >>>> who it is, regardless.
> >>>
> >>> That is exactly how it works. The device says "I need assistance", the
> >>> bus cycles generated by the CPU in response ask "Who are you?" and the
> >>> device responds with "I am number X".
> >
> >> This is usually done with the help of an Interupt Controller in the
> >> motherboard logic.
> >
> > True, on more modern systems. On older CPU's, if they had it at all,
> > it was built in (and not nearly as powerful).
> >
> I guess it depends on what you consider to be a modern system.
> The interrupts of an IBM 704 (vacuum tube, 1950s era) worked just this
> way. And all IBM's 70** series machines did too.
> So also did the GE 625, 635, and 645 machines.
> Also the mini-computers by DEC and Computer Control Corporation .
> And Honeywell.
> I cannot remember what the Control Data and Burroughs machines did.
> I would not call any of those "modern". They all had a "transfer vector
> table in the bottom addresses of hardware RAM.
Fair point. I was writing CPU but thinking "microprocessor" (as in
8080, 8085, 80x86, 68k, etc). Most all of the "innovations" on
microprocessors through the years have been copies, refinements, or
enhancements of architectural features that were present on mainframe
and or mini-computer processing units long before they arrived to the
microprocessor world.
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!goblin2!goblin.stu.neva.ru!feeder.erje.net!eu.feeder.erje.net!news.albasani.net!.POSTED!not-for-mail
From: The Natural Philosopher
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Tue, 03 Feb 2015 00:11:37 +0000
Organization: albasani.net
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.albasani.net vblLsGtbi77WLNChKk0aFJbvGQQ3rU8eu8hdk4JvT+nuVkGgqgwwkqfxzk9PRL8vGEQ6saXN2QHiHWgY3T/HGw==
NNTP-Posting-Date: Tue, 3 Feb 2015 00:11:37 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="UO3Pcg5Esr/HQe9rSBdq5wv6wYHnlQwnwo7dheZfQ8e9axTJqC9M94cMiGIH1fTIgtVG3Q7S5xplM7zlqe3QQgcjL82AypDZHhSAYfj08Hk8lCiW21XXsNM+hJcYbCu+"; mail-complaints-to="abuse-at-albasani.net"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
In-Reply-To:
Cancel-Lock: sha1:9ywoz0bQy1DvzoqU1BDA2kwHVO4=
Xref: panix comp.os.linux.misc:813979
On 30/01/15 13:19, ruben safir wrote:
> So how is it possible to eliminate that "middle man"? No matter how the
> interrupt routines are mapped as data in a system, you still need a
> routine to process the requests? How can it be eliminated?
Obviously it cant but what can be eliminated by hardware, is a routine
to decide which bit of hardware caused the interrupt.
Which you do by feeding that info as a hardware signal to the CPU, which
then 'adds' it as a number to a vector table to work out where to jump to
--
Everything you read in newspapers is absolutely true, except for the
rare story of which you happen to have first-hand knowledge. – Erwin Knoll
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!goblin1!goblin.stu.neva.ru!news.mixmin.net!aioe.org!.POSTED!not-for-mail
From: Jeroen Belleman
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Fri, 30 Jan 2015 09:28:21 +0100
Organization: Aioe.org NNTP Server
Message-ID:
References:
NNTP-Posting-Host: 4cdPr1/B+K+ySMbee62eSQ.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse-at-aioe.org
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130918 Thunderbird/17.0.9
X-Notice: Filtered by postfilter v. 0.8.2
Xref: panix comp.os.linux.misc:813930
On 2015-01-29 23:11, ruben safir wrote:
> 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.
Each device, when it generates an interrupt, tells the processor
which table index points to the correct handler. The processor then
jumps to that routine directly. The point is that it's not a routine,
in the sense of a sequence of CPU instructions, that does the work.
It's done directly by the hardware. (OK, microcoded CPUs may blur the
distinction.)
Of course, the location and size of the table are rigidly defined by
the hardware. (Or used to be, anyway.)
Jeroen Belleman
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!goblin1!goblin.stu.neva.ru!news.albasani.net!.POSTED!not-for-mail
From: The Natural Philosopher
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: Tue, 03 Feb 2015 00:08:10 +0000
Organization: albasani.net
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.albasani.net ndA0qAwno8fLP3kDM56nCyd3cLJ1RDiOVai70tfjr2pKIwt5UVUxrYKrEJGqnvTzXxBR0WTKgpsZlKkN0zod5Q==
NNTP-Posting-Date: Tue, 3 Feb 2015 00:08:11 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="dLbfO3UXkNiFkI7pf+OlMPu6EiJicMGTjjW30WMEYbEwz4vAtujzyWc+c/DO1j4+kaUDGztM/MtiXgz45saNat+CgORXZnZPzhNntvq7gipSO0gOwlC1fVXLbcGjFKcU"; mail-complaints-to="abuse-at-albasani.net"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
In-Reply-To:
Cancel-Lock: sha1:/L1/KuFLflpIWDQ+vC1gazL+7K0=
Xref: panix comp.os.linux.misc:813977
On 29/01/15 22:11, ruben safir wrote:
> 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.
>
I think what he means is that having a set of specific ISRs on a per
hardware basis is preferable to having one ISR and polling all the
hardware to find out which one did it, and then vectoring to ITS ISR
>
> Ruben
>
--
Everything you read in newspapers is absolutely true, except for the
rare story of which you happen to have first-hand knowledge. – Erwin Knoll
--------------070209080102000900040602
Content-Type: message/rfc822;
name="Re: operating systems design.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: operating systems design.eml"
Path: reader1.panix.com!panix!news.linkpendium.com!news.linkpendium.com!feeder.erje.net!us.feeder.erje.net!feed.news.qwest.net!mpls-nntp-02.inet.qwest.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.113.MISMATCH!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!spln!extra.newsguy.com!newsp.newsguy.com!news6
From: Charlie Gibbs
Newsgroups: comp.os.linux.misc
Subject: Re: operating systems design
Date: 3 Feb 2015 20:52:13 GMT
Organization: NewsGuy - Unlimited Usenet $23.95
Message-ID:
References:
NNTP-Posting-Host: p67685b8291620db5856209faef48eeaa5ad220302b0a0b42.newsdawg.com
User-Agent: slrn/1.0.1 (Linux)
X-Received-Bytes: 1514
X-Received-Body-CRC: 903757468
Xref: panix comp.os.linux.misc:814009
On 2015-02-03, The Natural Philosopher wrote:
> I think what he means is that having a set of specific ISRs on a per
> hardware basis is preferable to having one ISR and polling all the
> hardware to find out which one did it, and then vectoring to ITS ISR
On the other hand, you could have a master ISR to which the hardware
presents the address of the interrupting device, and this could be
used to index into a table of vectors to subsidiary ISRs appropriate
to each device. (This table could be built at boot time by scanning
for and identifying attached devices - or, as in the bad old days,
the table could be hard-coded as a result of the sysgen process.)
--
/~\ cgibbs-at-kltpzyxm.invalid (Charlie Gibbs) |
|
