🚀 go-pugleaf

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.