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

  1. Path: sparky!uunet!caen!hellgate.utah.edu!cc.usu.edu!ivie
  2. From: ivie@cc.usu.edu (CP/M lives!)
  3. Newsgroups: comp.arch
  4. Subject: Re: Graphics Systems
  5. Message-ID: <1992Jul30.104250.57660@cc.usu.edu>
  6. Date: 30 Jul 92 10:42:50 MDT
  7. References: <1992Jul27.110218.57519@cc.usu.edu> <1392@dms.agames.com>
  8. Organization: Utah State University
  9. Lines: 46
  10.  
  11. In article <1392@dms.agames.com>, albaugh@dms.agames.com (Mike Albaugh) writes:
  12. > the sort of feel that makes one chuckle at
  13. > comp.arch postings that talk about "real time" in terms of sub _milli_second
  14. > interrupt latencies :-)
  15.  
  16. On the subject of interrupts, it seems to me that it's the _modern_
  17. processors that have clunky interrupt handling. Consider:
  18.  
  19. 1965, PDP-8: Processor disables interrupts,
  20.              Saves program counter,
  21.              and jumps to a fixed location to execute code to figure out what 
  22.              caused the int.
  23.              The first thing this code has to do is save the accumulator and
  24.              processor status.
  25.              For complex systems, the code to figure out which device
  26.              caused an interrupt can be quite lengthy (it is usually 1/3
  27.              unconditional skips)
  28. 1970, PDP-11: Processor fetches a vector telling it what caused the int,
  29.               Saves program counter,
  30.               Saves processor status,
  31.               Fetches new processor status (giving it updated IPL),
  32.               Fetches new program counter,
  33.               and jumps to the interrupt service routine.
  34.               The interrupt service routine still has to save registers
  35.               it uses.
  36. 1978, VAX: Adds a separate stack pointer for processing interrupts so
  37.            that non-interrupt code doesn't have to worry as much about
  38.            how much stack space is used by interrupts (a lot under VMS).
  39.            The interrupt service routine still has to save registers it
  40.            uses.
  41. 1992, Alpha: See PDP-8, except there is no processor status to save.
  42.              In addition to figuring out what caused the interrupt, the 
  43.              code executed must figure out the new interrupt priority
  44.              level; this was simple on the -8, since there are only two
  45.              (enabled or disabled).
  46.  
  47. I realize that Alpha machines will have instruction caches and the RISC
  48. guys generally consider instruction fetches to be free, but I don't think
  49. the interrupt-handling code will generally be in cache; if it is, the
  50. system is probably spending too much of its time processing interrupts.
  51. At least the CISC machines generally have the decency to figure out which
  52. device caused the interrupt and go directly to the service routine without
  53. a lot of fuss and bother.
  54.  
  55. Roger Ivie
  56. ivie@cc.usu.edu
  57.