aglew@mcdurb.Urbana.Gould.COM (03/25/89)
I'm interested in architectural support (or lack thereof)
for interrupts (asynchronous events like I/O, not exceptions).
There's already been a bit of talk about this in some of these
response strings, but I'd like to open the whole thing up
and get some ideas flowing.
Here are some issues:
- When do you field the interrupt?
Immediately? (or when the interrupt level is unblocked)
Eventually (use some sort of time based scheduling)?
Batch (within 10 microseconds, or when 4 interrupts
are pending, whichever comes first)?
PROVOKER:
I have heard that the Control Data machines used in
radar processing really don't have interrupts at all.
Or, rather, they only have one type of interrupt, the
clock interrupt, and that all other events are basically
polled. And, my informant says, these were really nice
Real Time systems to work on, since the clock rate could
be set fairly high, and you had few sources of
indeterminacy.
- How do you dispatch the interrupt?
Vectored?
Through a single entry point?
DEAD:
Am I correct in saying that this is a dead issue - that
the "use a single entry point, since all UNIX does is
move everybody together" idea has won out? Or, is it just
that UNIX has never been written to take advantage of
vectored interrupts?
- What do you do with the state?
Stack?
Exchange jump?
Interrupt Control Block (I don't know of a generic term for
this - by it I mean the sort of thing that Gould Powernodes
and NPs have, where the interrupting PC and PSW is written
to a fixed location for each interrupt. Which could be
a register)
Register file?
- How do you exit from interrupt?
Note that I do not say "return from interrupt",
since not all interrupts return - instead, they scrunge
around on the stacks, and switch to a new process context.
Should you care about this?
On a higher level:
- Is it possible to create higher level models of interrupts and
interrupt structures so that interrupt driven applications can
be portable (to different machines running the same OS)?
Well, I guess many drivers already almost are. Are they?
Or:
- What can the architecture/OS do so that TCP/IP doesn't need
to be in the kernel?
Andy "Krazy" Glew aglew@urbana.mcd.mot.com uunet!uiucdcs!mcdurb!aglew
Motorola Microcomputer Division, Champaign-Urbana Design Center
1101 E. University, Urbana, Illinois 61801, USA.
My opinions are my own, and are not the opinions of my employer, or
any other organisation. I indicate my company only so that the reader
may account for any possible bias I may have towards our products.henry@utzoo.uucp (Henry Spencer) (03/26/89)
In article <28200294@mcdurb> aglew@mcdurb.Urbana.Gould.COM writes: >- How do you dispatch the interrupt? > Vectored? > Through a single entry point? > > DEAD: > Am I correct in saying that this is a dead issue - that > the "use a single entry point, since all UNIX does is > move everybody together" idea has won out? Or, is it just > that UNIX has never been written to take advantage of > vectored interrupts? Unix has exploited vectored interrupts, in modest ways, from the start. I think you've missed the real issue here: fancy interrupt hardware (as opposed to fancy software handling based on information supplied by the hardware) is an idea in decline because it's no faster than software handling and much less flexible. The reason why Unix implementations tend to run everything through a single point is that the hardware's interrupt semantics are so dismally ill-suited to what the software wants to do. In interrupts, as in instruction sets, the trend is to give the software people tools rather than preconceived solutions. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
chris@mimsy.UUCP (Chris Torek) (03/27/89)
In article <28200294@mcdurb> aglew@mcdurb.Urbana.Gould.COM writes, as a side point: >Am I correct in saying that this is a dead issue - that >the "use a single entry point, since all UNIX does is >move everybody together" idea has won out? Or, is it just >that UNIX has never been written to take advantage of >vectored interrupts? 4BSD Unix on the VAX uses all the vectors. The only `peculiarity' is that, e.g., all DH/DM receive interrupts wind up calling the same C routine, with the device index number as an argument. (Of course, on the SBI (780 and 8600), the hardware does not actually do the vectoring; the support code in locore.s makes these look like the other VAXen.) If the `vector' number is in a memory location, the difference between true vectored interrupts and software vectors is the instruction sequence move @actual_vector,reg add base,reg jump @reg which does not seem very expensive.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
aglew@mcdurb.Urbana.Gould.COM (03/28/89)
>4BSD Unix on the VAX uses all the vectors. The only `peculiarity' is >that, e.g., all DH/DM receive interrupts wind up calling the same C >routine, with the device index number as an argument. (Of course, on >the SBI (780 and 8600), the hardware does not actually do the >vectoring; the support code in locore.s makes these look like the other >VAXen.) That's what I meant by "having only a single entry point". All interrupt service routines branch to common code with an argument; BSD doesn't take advantage of interrupt vectors in that devices who don't need some of this code go through it anyway. (Course, whether there really are such devices is an open question).