home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8196 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.5 KB  |  52 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!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: <Brsx7o.G69@zoo.toronto.edu>
  6. Date: Wed, 22 Jul 1992 17:42:59 GMT
  7. References: <13v85hINN2og@rodan.UU.NET> <GLEW.92Jul14234349@pdx007.intel.com> <141o6mINN10h@rodan.UU.NET> <id.Z4JR.B6I@ferranti.com> <BrM8Gv.E3r@zoo.toronto.edu> <ADAMS.92Jul21011202@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
  8. Organization: U of Toronto Zoology
  9. Lines: 41
  10.  
  11. In article <ADAMS.92Jul21011202@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de> adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams) writes:
  12. >>   The theory behind things like bcopy boxes is that CPU cycles are slow
  13. >>   and costly compared to memory cycles.  Not any more, they aren't.
  14. >
  15. >... when were CPU cycles slower than memory cycles? 
  16.  
  17. Basically, in the old days.  For example, microcode made sense when the
  18. CPU was slow enough that using a memory to control it wouldn't slow it down.
  19. Not any more.
  20.  
  21. >Most literature I know of claims CPUs to be ten times faster than
  22. >memory...
  23.  
  24. *Today*, yes.
  25.  
  26. >This makes dedicated DMA-engines valuable, as they work
  27. >parallel to CPU and issue transfers only during bus idle states, 
  28. >just grabbing  the rest of memory bandwidth, but not more.
  29.  
  30. Uh, where do you find idle states?  If the CPU is that much faster than
  31. the memory, it wants all the memory bandwidth it can get, and the memory
  32. designers sweat and strain to give it more.  You get idle states only
  33. when the CPU is *slow*, so it can't use the full memory bandwidth.
  34.  
  35. Dedicated DMA engines make sense if
  36.  
  37.     1. the CPU can't move data around at full memory speed
  38.     2. normal execution doesn't use the full memory bandwidth
  39.     3. interrupt overhead is too high for timely device handling
  40.     4. bad hardware design cripples CPU data movement
  41.  
  42. It should be easy to see that as the CPU gets faster, it *can* move data
  43. around at full speed, and it wants all the bandwidth it can find (adding
  44. caches helps some, but doesn't solve the problem).  Item 3 can still be
  45. an issue, particularly on old architectures with clunky interrupt handling,
  46. or in applications with really ferocious data-movement requirements.
  47. Item 4 is constantly with us, its latest instantiation being caches that
  48. can't be bypassed (or can't be bypassed without a major performance hit).
  49. -- 
  50. There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
  51. mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
  52.