home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8332 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  2.0 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!swrinde!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!noose.ecn.purdue.edu!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: <55117@mentor.cc.purdue.edu>
  6. Date: 26 Jul 92 15:51:35 GMT
  7. References: <l6mlr0INN7tu@spim.mips.com> <54638@mentor.cc.purdue.edu> <id.YGRR.V_5@ferranti.com>
  8. Sender: news@mentor.cc.purdue.edu
  9. Organization: Purdue University Statistics Department
  10. Lines: 37
  11.  
  12. In article <id.YGRR.V_5@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
  13. >In article <54638@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  14. >> >        1) The compilers can't figure out how to use them often.
  15.  
  16. >> We keep hearing that compilers can do as well as humans.
  17.  
  18. >They do, but not in the same way. Similarly there are optimisations compilers
  19. >will use that humans can't.
  20.  
  21. If an optimization involves extensive calculation, a superfast sub-imbecile
  22. can do it better than a human.
  23.  
  24. >> >    or    2) Most realistic code doesn't lend itself to the mode.
  25.  
  26. >> What is realistic code?  I will code differently if there is hardware
  27. >> auto-increment for addresses.
  28.  
  29. >I won't.
  30.  
  31. Why not?  Because this would involve using an optimization not in the
  32. usual set?  This is the vicious cycle which has removed many useful and
  33. cheap instructions even from present computers.
  34.  
  35. >> I expect any good programmer to do as well;
  36.  
  37. >I expect any good programmer to code for the abstract machine defined for
  38. >the language. Remember, software longa, hardware brevis.
  39.  
  40. This might be reasonable if we had a language produced by people who have
  41. some respect for the capabilities of humans.  An analogy to the present
  42. programming languages would be a car-controller in which one could feed
  43. in a destination, but would not allow manual control.
  44. -- 
  45. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  46. Phone: (317)494-6054
  47. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  48. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  49.