home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8946 < prev    next >
Encoding:
Text File  |  1992-08-18  |  1.4 KB  |  40 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!sdd.hp.com!caen!sol.ctr.columbia.edu!eff!iWarp.intel.com|ichips!ichips!glew
  3. From: glew@pdx007.intel.com (Andy Glew)
  4. Subject: Re: interrupt overhead
  5. In-Reply-To: henry@zoo.toronto.edu's message of 23 Jul 92 21:08:31 GMT
  6. Message-ID: <GLEW.92Aug18145622@pdx007.intel.com>
  7. Sender: news@ichips.intel.com (News Account)
  8. Organization: Intel Corp., Hillsboro, Oregon
  9. References: <13v85hINN2og@rodan.UU.NET> <GLEW.92Jul14234349@pdx007.intel.com>
  10.     <Brsx7o.G69@zoo.toronto.edu> <1992Jul22.163956.57436@cc.usu.edu>
  11.     <Brus8r.2K7@zoo.toronto.edu> <Brv1E9.76t@zoo.toronto.edu>
  12. Date: Tue, 18 Aug 1992 22:56:22 GMT
  13. Lines: 25
  14.  
  15.     >Pretty much the inescapable minimum is two pipeline breaks plus a cycle for
  16.     >the "return from interrupt" instruction...
  17.  
  18.     John Carr has pointed out to me, in private mail, that a clever CPU
  19.     doesn't actually need to flush its pipelines, if the things in the
  20.     pipeline are guaranteed not to incur exceptions.  So it's potentially
  21.     not much worse than a couple of taken branches.
  22.  
  23. This is a latency versus thruput tradeoff.
  24.  
  25. If you insert interrupts at the end of the pipe, instead of clearing
  26. the pipe, you are potentially adding to the interrupt delivery
  27. latency.
  28.  
  29.  
  30. --
  31.  
  32. Andy Glew, glew@ichips.intel.com
  33. Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
  34. Hillsboro, Oregon 97124-6497
  35.  
  36. This is a private posting; it does not indicate opinions or positions
  37. of Intel Corp.
  38.  
  39. Intel Inside (tm)
  40.