home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8235 < prev    next >
Encoding:
Text File  |  1992-07-23  |  1.7 KB  |  34 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!cs.utexas.edu!torn!utzoo!henry
  3. From: henry@zoo.toronto.edu (Henry Spencer)
  4. Subject: Re: CISC Microcode (was Re: RISC Mainframe)
  5. Message-ID: <Brus8r.2K7@zoo.toronto.edu>
  6. Date: Thu, 23 Jul 1992 17:50:46 GMT
  7. References: <13v85hINN2og@rodan.UU.NET> <GLEW.92Jul14234349@pdx007.intel.com> <Brsx7o.G69@zoo.toronto.edu> <1992Jul22.163956.57436@cc.usu.edu>
  8. Organization: U of Toronto Zoology
  9. Lines: 23
  10.  
  11. In article <1992Jul22.163956.57436@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
  12. >> Item 3 can still be
  13. >> an issue, particularly on old architectures with clunky interrupt handling,
  14. >
  15. >What do you mean by "clunky interrupt handling"?
  16.  
  17. Many, many CPU cycles needed to get into and out of an interrupt, so it's
  18. impossible to take very many of them or respond quickly to one.  You have
  19. to figure in both hardware and software interrupt overhead; the relevant
  20. metric is elapsed time between stopping mainline execution and starting
  21. the interrupt handler *for that specific interrupt*.  Time spent figuring
  22. out deciding who gets to handle this one, or saving and restoring registers
  23. so he can be invoked safely, is part of the overhead regardless of whether
  24. it's in software or hardware.
  25.  
  26. Pretty much the inescapable minimum is two pipeline breaks plus a cycle for
  27. the "return from interrupt" instruction.  There are CPUs that approach this
  28. for simple cases where the interrupt can be dealt with quickly (they do
  29. typically incur somewhat more overhead if the interrupt handler wants to
  30. run for a while and use substantial resources).
  31. -- 
  32. There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
  33. mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
  34.