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

Groups > comp.os.linux.hardware > #2713 > unrolled thread

Operating System Design

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

Contents

  Operating System Design ruben safir <ruben@mrbrklyn.com> - 2015-01-29 17:11 -0500
    Re: Operating System Design "Vince Coen" <VBCoen@gmail.com> - 2015-01-29 22:29 +0000
    Re: Operating System Design Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-01-29 17:38 -0500
    Re: Operating System Design Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-01-29 16:07 -0700
      Re: Operating System Design Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-01-29 16:16 -0700
    Re: Operating System Design David Brown <david.brown@hesbynett.no> - 2015-01-30 09:00 +0100
      Re: Operating System Design ruben safir <ruben@mrbrklyn.com> - 2015-02-01 19:34 -0500

#2713 — Operating System 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]

#2714

Hello ruben!

Lots of words to say that they IHR must be quick so minimum of code.
Likewise the routines themselves must also be fast to ensure that no data
is lost allowing for a secondary interrupt to occur etc.

Somewhere in my libary I have 2 books on OS design with one covering the
design and implementation of Minux (this one is worth reading) but the
other is a lot older and I used it when helping to develop VME for ICL in
the early 70's. Proved very helpfull in avioding various traps.
Must remember to dig it up and by memory written around 1969-1972.
Written and published in the USA.

Vince

Thursday January 29 2015 22:11, ruben safir wrote to All:

 > 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



Vince

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

#2715

On Thursday January 29 2015 17:11, in comp.os.linux.hardware, "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

Don't know the book, so my remarks will have to be somewhat generic.

> 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?  


Certain hardware interrupts cause an execution branch to a specific
location. Typically, the hardware will provide some identifying information
available through an I/O call, and the logic branched to must then poll
each eligible device for that information. Once the device has been
identified and the information extracted, the logic can then process the
interrupt condition.

Certain software interrupts also can cause an execution branch to a specific
location. Typically, the software interrupt code will provide some
identifying information available through inspection of the memory pointed
to by interrupt program-counter. Once this information has been extracted,
the logic can then process the interrupt condition.

Both of these types of interrupt expect to execute logic at a specific
location, hardwired into the interrupt mechanism.

[snip]

HTH
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#2716

ruben safir <ruben@mrbrklyn.com> writes:

> I'm wondering if anyone has a background in operating system design.
> I'm taking a class is OS's and the text is
>
> OPERATING
> SYSTEM
> CONCEPTS
> ABRAHAM SILBERSCHATZ
> 9th edition, and it says something that is puzzling me
>
>
>
> "Interrupts are an important part of a computer architecture. Each
> computer design has its own interrupt mechanism, but several functions
> are common. The interrupt must transfer control to the appropriate
> interrupt service routine. The straightforward method for handling this
> transfer would be to invoke a generic routine to examine the interrupt
> information. The routine, in turn, would call the interrupt-specific
> handler. However, interrupts must be handled quickly"
>
> " Since only a predefined number of interrupts is possible, a table of
> pointers to interrupt routines can be used instead*** to provide the
> necessary speed. The interrupt routine is called indirectly through the
> table, with no intermediate routine needed. Generally, the table of
> pointers is stored in low memory (the first hundred or so locations).
> These locations hold the addresses of the interrupt service routines for
> the various devices. This array, or interrupt vector, of addresses is
> then indexed by a unique device number, given with the interrupt
> request, to provide the address of the interrupt service routine for
> the interrupting device. Operating systems as different as Windows and
> UNIX dispatch interrupts in this manner."
>
>
> ***  Instead of what?  Just because you have a table of pointers to
> routines doesn't change the need for a routine, a generic routine
> perhaps, from accessing that table.

In an interrupt vector table like he's describing, the hardware indexes
the table directly and jumps straight to the ISR without any software
intervention before it gets there.

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

#2717

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> ruben safir <ruben@mrbrklyn.com> writes:
>
>> I'm wondering if anyone has a background in operating system design.
>> I'm taking a class is OS's and the text is
>>
>> OPERATING
>> SYSTEM
>> CONCEPTS
>> ABRAHAM SILBERSCHATZ
>> 9th edition, and it says something that is puzzling me
>>
>>
>>
>> "Interrupts are an important part of a computer architecture. Each
>> computer design has its own interrupt mechanism, but several functions
>> are common. The interrupt must transfer control to the appropriate
>> interrupt service routine. The straightforward method for handling this
>> transfer would be to invoke a generic routine to examine the interrupt
>> information. The routine, in turn, would call the interrupt-specific
>> handler. However, interrupts must be handled quickly"
>>
>> " Since only a predefined number of interrupts is possible, a table of
>> pointers to interrupt routines can be used instead*** to provide the
>> necessary speed. The interrupt routine is called indirectly through the
>> table, with no intermediate routine needed. Generally, the table of
>> pointers is stored in low memory (the first hundred or so locations).
>> These locations hold the addresses of the interrupt service routines for
>> the various devices. This array, or interrupt vector, of addresses is
>> then indexed by a unique device number, given with the interrupt
>> request, to provide the address of the interrupt service routine for
>> the interrupting device. Operating systems as different as Windows and
>> UNIX dispatch interrupts in this manner."
>>
>>
>> ***  Instead of what?  Just because you have a table of pointers to
>> routines doesn't change the need for a routine, a generic routine
>> perhaps, from accessing that table.
>
> In an interrupt vector table like he's describing, the hardware indexes
> the table directly and jumps straight to the ISR without any software
> intervention before it gets there.

After reading some of the other responses, I'll give a concrete example
(which sounds like the machine he has in mind):  the interrupt mechanism
on the old DEC PDP-11.

On the PDP-11, a device requested an interrupt by asserting a bus
request line.  The CPU would respond by asserting a corresponding bus
grant line (there was a mechanism for resolving multiple simultaneous
interrupt requests, which is not relevant here).

After receiving the bus grant, the device would place a memory address
on the bus address lines.  This was the address of the device's
"interrupt vector".

The CPU would retrieve a new program counter (PC) and processor status
word (PSW) from the four bytes at this address, push the old PC and PSW
on the stack, and begin execution at the new PC.

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

#2718

On 29/01/15 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.
> 

When a cpu receives an unmasked interrupt signal (you will probably
learn about masking interrupts later - generally, the OS can control
which interrupts are enabled), it must do three things:

1. It must pause execution of the current instruction stream
2. It must store critical state data so that normal execution can be
resumed later.
3. It must jump to some user/system code to handle the interrupt.

Step 1 here is mostly internal to the processor, and won't be visible to
the OS or programmers (except that it can affect the reaction time for
interrupts, which can be critical in embedded systems).

Step 2 varies tremendously between processor types, but it generally
involves storing a minimal set of registers in a safe place, so that the
software interrupt handler can run (and save other registers as needed).
 CISC processors generally push the current stack pointer and the flag
register onto the stack.  For more complex CISC processors such as the
68040, there can be other registers saved to keep track of the state of
long-running instructions (like block copy instructions). RISC
processors like the PPC save them in dedicated "interrupt save"
registers.  Some processors, like the ARM responding to a "fast
interrupt", enable a dedicated register bank.  And some, like the
Cortex-M3, save a number of registers so that the interrupt handlers can
be written as plain C functions without need for assembly or special
handling.

Step 3 is where the processor figures out what code to run next.  This
again varies between processors.  For some, there is a single fixed
address that is always used - then it is up to the user code to figure
out the source of the interrupt, and handle it (using a table of
function pointers, a switch statement, a series of if's, etc.).  Some
processors have dedicated internal registers for interrupt routine
addresses.  Some will have an interrupt controller module (either
builtin, or as a separate device) that figures out the interrupt source
and gets an appropriate handler address from internal registers or a
memory table.  And other cpus get an interrupt number directly, and use
that to look up a table of handler addresses (typically based at a
configurable address).

However the handler address is discovered, the processor then jumps to
the code at that address.  It is up to that code to figure out what
caused the interrupt (if the cpu supports a table of handlers, the code
will already have a fair idea).  It also needs to store additional
registers and processor state, and then deal with the interrupt itself.
 Afterwards it can either return to the interrupted code, or cause some
sort of context switch (a more advanced topic that you will get to later
in the book, I expect).

For most processors, this handler requires some assembly programming or
at least special compiler extensions and attributes - it is not a
"normal" C function.  And there are always restrictions on how handler
code interacts with the OS and system calls.


A note on terminology - the term "interrupt vector" is sometimes used to
mean a table of pointers to interrupt handlers, as used in the quotation
you gave.  But it can also be used to mean simply /a/ pointer to an
interrupt handler.  Thus sometimes one talks about "a table of interrupt
vectors".  I've tried to avoid the term here, to avoid confusion - I
recommend you do so too unless you make the meaning explicitly clear.

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

#2719

On 01/30/2015 03:00 AM, David Brown wrote:
> On 29/01/15 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.
>>
> 
> When a cpu receives an unmasked interrupt signal (you will probably
> learn about masking interrupts later - generally, the OS can control
> which interrupts are enabled), it must do three things:
> 
> 1. It must pause execution of the current instruction stream
> 2. It must store critical state data so that normal execution can be
> resumed later.
> 3. It must jump to some user/system code to handle the interrupt.
> 
> Step 1 here is mostly internal to the processor, and won't be visible to
> the OS or programmers (except that it can affect the reaction time for
> interrupts, which can be critical in embedded systems).
> 
> Step 2 varies tremendously between processor types, but it generally
> involves storing a minimal set of registers in a safe place, so that the
> software interrupt handler can run (and save other registers as needed).
>  CISC processors generally push the current stack pointer and the flag
> register onto the stack.  For more complex CISC processors such as the
> 68040, there can be other registers saved to keep track of the state of
> long-running instructions (like block copy instructions). RISC
> processors like the PPC save them in dedicated "interrupt save"
> registers.  Some processors, like the ARM responding to a "fast
> interrupt", enable a dedicated register bank.  And some, like the
> Cortex-M3, save a number of registers so that the interrupt handlers can
> be written as plain C functions without need for assembly or special
> handling.
> 
> Step 3 is where the processor figures out what code to run next.  This
> again varies between processors.  For some, there is a single fixed
> address that is always used - then it is up to the user code to figure
> out the source of the interrupt, and handle it (using a table of
> function pointers, a switch statement, a series of if's, etc.).  Some
> processors have dedicated internal registers for interrupt routine
> addresses.  Some will have an interrupt controller module (either
> builtin, or as a separate device) that figures out the interrupt source
> and gets an appropriate handler address from internal registers or a
> memory table.  And other cpus get an interrupt number directly, and use
> that to look up a table of handler addresses (typically based at a
> configurable address).
> 
> However the handler address is discovered, the processor then jumps to
> the code at that address.  It is up to that code to figure out what
> caused the interrupt (if the cpu supports a table of handlers, the code
> will already have a fair idea).  It also needs to store additional
> registers and processor state, and then deal with the interrupt itself.
>  Afterwards it can either return to the interrupted code, or cause some
> sort of context switch (a more advanced topic that you will get to later
> in the book, I expect).
> 
> For most processors, this handler requires some assembly programming or
> at least special compiler extensions and attributes - it is not a
> "normal" C function.  And there are always restrictions on how handler
> code interacts with the OS and system calls.
> 
> 
> A note on terminology - the term "interrupt vector" is sometimes used to
> mean a table of pointers to interrupt handlers, as used in the quotation
> you gave.  But it can also be used to mean simply /a/ pointer to an
> interrupt handler.  Thus sometimes one talks about "a table of interrupt
> vectors".  I've tried to avoid the term here, to avoid confusion - I
> recommend you do so too unless you make the meaning explicitly clear.
> 
> 
> 


Now it says later:

 The interrupt-driven nature of an operating system defines that
system’s general structure. For each type of interrupt, separate
segments of code in the operating system determine what action should be
taken. An interrupt service routine is provided to deal with the
interrupt. Since the operating system and the users share the hardware
and software

~~~~~~~~~~~

You seem to explain it much better than they do.  These poorly written
text books are getting me depressed.

[toc] | [prev] | [standalone]

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

csiph-web