home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8269 < prev    next >
Encoding:
Internet Message Format  |  1992-07-24  |  2.2 KB

  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  2. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  3. Newsgroups: comp.arch
  4. Subject: Re: CISC Microcode (was Re: RISC Mainframe)
  5. Message-ID: <54987@mentor.cc.purdue.edu>
  6. Date: 24 Jul 92 13:14:48 GMT
  7. References: <Brsx7o.G69@zoo.toronto.edu> <1992Jul22.163956.57436@cc.usu.edu> <Brus8r.2K7@zoo.toronto.edu>
  8. Sender: news@mentor.cc.purdue.edu
  9. Organization: Purdue University Statistics Department
  10. Lines: 31
  11.  
  12. In article <Brus8r.2K7@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
  13. >In article <1992Jul22.163956.57436@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
  14. |>> Item 3 can still be
  15. |>> an issue, particularly on old architectures with clunky interrupt handling,
  16.  
  17. |>What do you mean by "clunky interrupt handling"?
  18.  
  19. >Many, many CPU cycles needed to get into and out of an interrupt, so it's
  20. >impossible to take very many of them or respond quickly to one.  You have
  21. >to figure in both hardware and software interrupt overhead; the relevant
  22. >metric is elapsed time between stopping mainline execution and starting
  23. >the interrupt handler *for that specific interrupt*.  Time spent figuring
  24. >out deciding who gets to handle this one, or saving and restoring registers
  25. >so he can be invoked safely, is part of the overhead regardless of whether
  26. >it's in software or hardware.
  27.  
  28. >Pretty much the inescapable minimum is two pipeline breaks plus a cycle for
  29. >the "return from interrupt" instruction.  There are CPUs that approach this
  30. >for simple cases where the interrupt can be dealt with quickly (they do
  31. >typically incur somewhat more overhead if the interrupt handler wants to
  32. >run for a while and use substantial resources).
  33.  
  34. This "inescapable minimum" is at least partly due to the failure to realize
  35. that planned interrupts are becoming more necessary.  The initial overhead
  36. of an interrupt should be no greater than that for a subroutine call, and
  37. possibly less.  FULL context switching needs speeding up.
  38. -- 
  39. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  40. Phone: (317)494-6054
  41. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  42. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  43.