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

Groups > comp.os.linux.misc > #13512

Re: operating systems design

Show all headers | View raw

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

Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web