home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 17889 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  3.5 KB
  1. Xref: sparky comp.sys.amiga.programmer:17889 comp.sys.amiga.hardware:22139
  2. Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
  3. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!winikoff
  4. From: winikoff@cs.mu.OZ.AU (Michael David WINIKOFF)
  5. Subject: Re: CISC and RISC
  6. Message-ID: <9236416.13537@mulga.cs.mu.OZ.AU>
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <amipb.04wr@amipb.gna.org> <37844@cbmvax.commodore.com> <Bz8FD1.Dxt@ns1.nodak.edu> <BzByvD.FA9@news.cs.andrews.edu> <1gnl0mINNpq2@crcnis1.unl.edu> <1992Dec16.185521.21232@ichips.intel.com> <jimomura.02k4@tndb.UUCP> <9235716.13776@mulga.cs.mu.OZ.AU> <jimomura.02ki@tndb.UUCP>
  9. Date: Tue, 29 Dec 1992 05:09:01 GMT
  10. Lines: 76
  11.  
  12. jimomura@tndb.UUCP (Jim Omura) writes:
  13.  
  14. >In article <9235716.13776@mulga.cs.mu.OZ.AU> winikoff@cs.mu.OZ.AU (Michael David WINIKOFF) writes:
  15. >>jimomura@tndb.UUCP (Jim Omura) writes:
  16. >>
  17. >>[Lots of quotes deleted]
  18. >>
  19.  
  20. >     Well, yes, I know that.  That's why I raised the issue in *this*
  21. >discussion where nobody else has.
  22. Ack.
  23.  
  24. >>In shared memory machines one relies heavily on caches to reduce the demand
  25. >>on the bus.
  26. >>
  27. >>Another solution to having multiple processors is to build distributes
  28. >>memory machines.
  29.  
  30. >     Let me repeat "there are going to be times where the various
  31. >busses are going to be the main bottleneck".  This will be true
  32. >in spite of distributed memory and caching.  Actually, I thought
  33. >I implied that fairly well.
  34. >:-)
  35.  
  36. Yup, if these times don't occur that often though then you're fine.
  37.  
  38. >>Essentially what (I think) you're saying is "we shouldn't use the fastest
  39. >>CPUs we can on a multiprocessor machines since they'll be tying up more
  40. >>bus bandwidth then slower processors"
  41.  
  42. >     That's close.  To state it more accurately, we're reaching a
  43. >point where certain classes of applications which push designs
  44. >in various directions have significant representation in the market.
  45. >Considering all the design specification factors (user needs and
  46. >preferences, design costs, material costs and production costs),
  47. >better performance may be achieved where overall system architectures
  48. >are optimized towards certain applications.  And some CPUs will
  49. >be better suited that others in this overall context.  More
  50. >specifically, in some designs, super-scalar RISCs simply may not
  51. >give performance as good as CISC.  Furthermore, there should be
  52.  
  53. Sure - just leave out the cache :-)
  54.  
  55. >advantages in designing CPUs with more of an eye on final applications
  56. >and working backwards through the overall system architecture
  57. >than there has been in the past.  This may be happening in the
  58.  
  59. Huh? Isn't this what the RISC approach is all about?
  60. [Ref. Computer architecture: a quantitative approach. Hennesy & Patterson]
  61.  
  62. >Apple/IBM/Motorola project -- I don't know.
  63.  
  64. Whoa! That's a mouthful. You sure you ain't a lawyer/politician/marketroid? :-)
  65.  
  66. >     I might also add that I doubt that we're close to seeing the
  67. >ultimate designs in any of these classes.
  68.  
  69. I don't think there ever will be an "ultimate" design since the technology
  70. used to implement designs is continuously developing.
  71.  
  72. >     Incidentally, the latest word I have is that the physical signals
  73. >in the Apple/IBM/Motorola RISC are essentially 88000 signals, so
  74. >that might be a good reason to design the next generation Amigas
  75. >on 88000's.
  76.  
  77. >...
  78.  
  79. >--
  80.  
  81. >Jim Omura, (416) 652-3880
  82. >'jimomura@lsuc'
  83. -- 
  84.  
  85. --------------------------------------------------------------------------------
  86. Software Engineering: Quality through Deforestation.
  87.  
  88.