jimv@pzbaum.uucp (Jim Valerio) (06/14/89)
In article <m0fWHgn-0001kaC@mipon2.intel.com> mcg@mipon2.UUCP (Steven McGeady) writes: >In article <3427@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >>There's another pitfall here. Some machines use the same register >>window mechanism to handle interrupts, automatically shifting to >>a new set. If the interrupt hits you at just the wrong call depth, >>you get an automatic register spill. > >Quite the contrary. It is easy to reserve a register set soley for interrupts. >This makes actual interrupt latency fast and predictable. The interrupt >routine never needs to save any context-dependent registers. This allows the >960 architecture to have both fast and predictable length interrupts. It's not just as easy as reserving an interrupt register set. In the 960 architecture, interrupts are prioritized, and dispatched using an interrupt vector table. What if two interrupts arrive roughly simultaneously but in reverse priority order: which interrupt would get the reserved frame? And let's carry this out a bit further. I believe the existing 960 implementations have 4 interrupt pins, 2 of which are configurable as either straight interrupt lines or as cascade handshake lines to an 8259A interrupt controller. Assuming a similar arrangement on some 960 implementation that supports a reserved register set for interrupts, for which subset of interrupts would the reserved frame be allocated? What approaches would other interrupt register set architectures take? Would the interrupt pins or the interrupt architecture be re-defined from existing implementations to support a "fast and predictable" reserved interrupt register set? -- Jim Valerio jimv%pzbaum@omepd.intel.com, {reed,radix,omepd}!pzbaum!jimv