Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #13504 > unrolled thread

operating systems design

Back to article view | Back to comp.os.linux.misc

Contents

  operating systems design ruben safir <ruben@mrbrklyn.com> - 2015-01-29 17:11 -0500
    Re: operating systems design Rich <rich@example.invalid> - 2015-01-29 22:29 +0000
      Re: operating systems design ruben safir <ruben@mrbrklyn.com> - 2015-01-30 08:19 -0500
        Re: operating systems design "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2015-01-30 09:01 -0500
        Re: operating systems design Robert Heller <heller@deepsoft.com> - 2015-01-30 08:07 -0600
          Re: operating systems design Jeroen Belleman <jeroen@nospam.please> - 2015-01-30 15:43 +0100
            Re: operating systems design Robert Heller <heller@deepsoft.com> - 2015-01-30 09:09 -0600
        Re: operating systems design Rich <rich@example.invalid> - 2015-01-30 15:21 +0000
          Re: operating systems design Robert Heller <heller@deepsoft.com> - 2015-01-30 11:27 -0600
            Re: operating systems design Rich <rich@example.invalid> - 2015-01-30 19:10 +0000
              Re: operating systems design Jean-David Beyer <jeandavid8@verizon.net> - 2015-02-02 08:29 -0500
                Re: operating systems design Rich <rich@example.invalid> - 2015-02-02 15:09 +0000
        Re: operating systems design The Natural Philosopher <tnp@invalid.invalid> - 2015-02-03 00:11 +0000
    Re: operating systems design Jeroen Belleman <jeroen@nospam.please> - 2015-01-30 09:28 +0100
    Re: operating systems design The Natural Philosopher <tnp@invalid.invalid> - 2015-02-03 00:08 +0000
      Re: operating systems design Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-02-03 20:52 +0000
        Re: operating systems design The Natural Philosopher <tnp@invalid.invalid> - 2015-02-03 21:06 +0000
        Re: operating systems design Rich <rich@example.invalid> - 2015-02-03 21:19 +0000

#13504 — operating systems design

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

[toc] | [next] | [standalone]

#13505

ruben safir <ruben@mrbrklyn.com> 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.

[toc] | [prev] | [next] | [standalone]

#13507

On 01/29/2015 05:29 PM, Rich wrote:
> ruben safir <ruben@mrbrklyn.com> 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

[toc] | [prev] | [next] | [standalone]

#13508

On Fri, 30 Jan 2015 08:19:33 -0500, ruben safir <ruben@mrbrklyn.com> 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.)

[toc] | [prev] | [next] | [standalone]

#13509

At Fri, 30 Jan 2015 08:19:33 -0500 ruben safir <ruben@mrbrklyn.com> wrote:

> 
> On 01/29/2015 05:29 PM, Rich wrote:
> > ruben safir <ruben@mrbrklyn.com> 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@deepsoft.com       -- Webhosting Services
                             

[toc] | [prev] | [next] | [standalone]

#13510

On 2015-01-30 15:07, Robert Heller wrote:
> At Fri, 30 Jan 2015 08:19:33 -0500 ruben safir <ruben@mrbrklyn.com> wrote:
>
>>
>> On 01/29/2015 05:29 PM, Rich wrote:
>>> ruben safir <ruben@mrbrklyn.com> 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

[toc] | [prev] | [next] | [standalone]

#13511

At Fri, 30 Jan 2015 15:43:18 +0100 Jeroen Belleman <jeroen@nospam.please> wrote:

> 
> On 2015-01-30 15:07, Robert Heller wrote:
> > At Fri, 30 Jan 2015 08:19:33 -0500 ruben safir <ruben@mrbrklyn.com> wrote:
> >
> >>
> >> On 01/29/2015 05:29 PM, Rich wrote:
> >>> ruben safir <ruben@mrbrklyn.com> 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@deepsoft.com       -- Webhosting Services
               

[toc] | [prev] | [next] | [standalone]

#13512

ruben safir <ruben@mrbrklyn.com> wrote:
> On 01/29/2015 05:29 PM, Rich wrote:
> > ruben safir <ruben@mrbrklyn.com> 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".

[toc] | [prev] | [next] | [standalone]

#13513

At Fri, 30 Jan 2015 15:21:44 +0000 (UTC) Rich <rich@example.invalid> wrote:

> 
> ruben safir <ruben@mrbrklyn.com> wrote:
> > On 01/29/2015 05:29 PM, Rich wrote:
> > > ruben safir <ruben@mrbrklyn.com> 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@deepsoft.com       -- Webhosting Services
                      

[toc] | [prev] | [next] | [standalone]

#13514

Robert Heller <heller@deepsoft.com> wrote:
> At Fri, 30 Jan 2015 15:21:44 +0000 (UTC) Rich <rich@example.invalid> wrote:
> > ruben safir <ruben@mrbrklyn.com> 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.

[toc] | [prev] | [next] | [standalone]

#13541

On 01/30/2015 02:10 PM, Rich wrote:
> Robert Heller <heller@deepsoft.com> wrote:
>> At Fri, 30 Jan 2015 15:21:44 +0000 (UTC) Rich <rich@example.invalid> wrote:
>>> ruben safir <ruben@mrbrklyn.com> 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

[toc] | [prev] | [next] | [standalone]

#13542

Jean-David Beyer <jeandavid8@verizon.net> wrote:
> On 01/30/2015 02:10 PM, Rich wrote:
> > Robert Heller <heller@deepsoft.com> wrote:
> >> At Fri, 30 Jan 2015 15:21:44 +0000 (UTC) Rich <rich@example.invalid> wrote:
> >>> ruben safir <ruben@mrbrklyn.com> 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.

[toc] | [prev] | [next] | [standalone]

#13555

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

[toc] | [prev] | [next] | [standalone]

#13506

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

[toc] | [prev] | [next] | [standalone]

#13553

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

[toc] | [prev] | [next] | [standalone]

#13585

On 2015-02-03, The Natural Philosopher <tnp@invalid.invalid> 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@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#13589

On 03/02/15 20:52, Charlie Gibbs wrote:
> On 2015-02-03, The Natural Philosopher <tnp@invalid.invalid> 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.)
>

That is roughly what I said..

-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [next] | [standalone]

#13590

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2015-02-03, The Natural Philosopher <tnp@invalid.invalid> 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.)

Which is exactly what the second paragraph quoted from the textbook by
the OP described.  That portion is just implimented in hardware rather
than by running software (I'm ignoring microcode to perform the above
function right now, which would blur the distinction).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web