🚀 go-pugleaf

>With interrupt processing time being such a critical path in the system,
>I think not having auto-increment is a definite win (IMHO).
>-- 
>David Sonnier@Tandem Computers, Inc. 14231 Tandem Blvd. Austin, Texas  78728
>...!{rutgers,ames,ut-sally}!cs.utexas.edu!halley!dps        (512) 244-8394

What data can people provide that says that interrupts are a critical
path in the system?
     That didn't come out quite right - how do you distinguish between 
[A] the work that has to be done *some* time, that you can choose to be done at
interrupt time or elsewhere, and [B] the work that is inherent in
processing interrupts, and can be minimized by making the interrupt 
dispatch/return more efficient.
     Several comments to the effect that "the work the hardware does
in interrupt dispatch is only a miniscule fraction of our interrupt
bottleneck" make me think that [A] is the bottleneck.
     If so, then how really important would be a bit of work in the
interrupt handler, to decode and back up autoincremented registers?
Ie. how really important is a [B] << [A]?  (Especially if you have an
instruction set that is easy to decode, unlike the VAXes', so the 
autoincrement would be easy to back up (BTW, on Gould machines we had 
to do a little bit of instruction decoding to restore state on an
interrupt (usually just +/- 2 or 4 on the PC) -- it was fast and easy)).


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.