home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8375 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  4.5 KB
  1. Path: sparky!uunet!usc!elroy.jpl.nasa.gov!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: <55294@mentor.cc.purdue.edu>
  6. Date: 28 Jul 92 13:05:18 GMT
  7. References: <id.YGRR.V_5@ferranti.com> <55117@mentor.cc.purdue.edu> <id.RKUR.GFF@ferranti.com>
  8. Sender: news@mentor.cc.purdue.edu
  9. Organization: Purdue University Statistics Department
  10. Lines: 90
  11.  
  12. In article <id.RKUR.GFF@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
  13. >In article <55117@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  14. >> In article <id.YGRR.V_5@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
  15. >> >In article <54638@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  16.  
  17.             ......................
  18.  
  19. >> If an optimization involves extensive calculation, a superfast sub-imbecile
  20. >> can do it better than a human.
  21.  
  22. >I'm glad you noticed it. We're agreed then that these idiot savants generate
  23. >code that is as fast as a human can write, if not the same sort of code. 
  24.  
  25. This is not always the case.  It is quite possible that a simple idea which
  26. a human can see is not within the category of those known to the compiler.
  27. No compiler can change the algorithm to one that it does not know about.
  28. I can, and do.
  29.  
  30. It is like the case, almost 30 years ago, when a colleague of mine went
  31. to get help in programming the computation of integrals with a set of
  32. parameters.  The programmer objected to using a power series to compute
  33. each integral, saying that numerical computation of integrals could
  34. only be done by numerical integration procedures.  This is the difference
  35. between the imbecilic compiler and the intelligent human.
  36.  
  37. It is also quite possible that a human can see that a relatively simple
  38. change in hardware can eliminate a clumsy set of operations, and get a
  39. great speedup.  
  40.  
  41. >> >> >    or    2) Most realistic code doesn't lend itself to the mode.
  42.  
  43. >> >> What is realistic code?  I will code differently if there is hardware
  44. >> >> auto-increment for addresses.
  45.  
  46. >> >I won't.
  47.  
  48. >> Why not?  Because this would involve using an optimization not in the
  49. >> usual set?
  50.  
  51. >Because allowing the compiler to find machine-specific optimisations is more
  52. >cost effective than doing it myself. Because the code I write runs on Sparcs,
  53. >68000s, 80386s, 80286s, VAXen, and 68020s. Because next month it might be
  54. >running on MIPS or 88000. Next year it might be running on Supersparc or Alpha.
  55. >Because optimising when you don't need to is a waste of resources.
  56.  
  57. This means that the language should be expanded to include the alternatives.
  58. This expansion is likely to be at what could be called a basic stage, not by
  59. adding on subroutines and functions.  
  60.  
  61.             .....................
  62.  
  63. >> >I expect any good programmer to code for the abstract machine defined for
  64. >> >the language. Remember, software longa, hardware brevis.
  65.  
  66. >> This might be reasonable if we had a language produced by people who have
  67. >> some respect for the capabilities of humans.
  68.  
  69. >We do. We have dozens of them.
  70.  
  71. Name one in which recognizes the various things I have previously published
  72. in a syntax intended for fast use by a human being.  Lisp seems to have a
  73. fairly reasonable collection of primitives, but a human being should not 
  74. be REQUIRED to use clumsy prenex notation.  I am not convince that Lisp
  75. has enough.  Any adequate language should have an extensible class of
  76. operators, list (not struct) results, etc.  There MAY have been a fair
  77. reason to leave some of these out when compilers were weak, but if the
  78. compiler is as good as is claimed, NO.
  79.  
  80. >> An analogy to the present
  81. >> programming languages would be a car-controller in which one could feed
  82. >> in a destination, but would not allow manual control.
  83.  
  84. >Analogies are like instant coffee, but what you want is a little more primitive
  85. >than that. I don't know about you, but I'm glad they don't make cars with
  86. >manual chokes any more, or that need double-clutching when you shift.
  87.  
  88. Having had choke problems, I would prefer that cars had manual choke 
  89. overrides, to be used when necessary.  The only problem I have ever had
  90. with a manual choke is forgetting to turn it off.
  91.  
  92. A speaker almost missed giving a talk here because of a computer-controlled
  93. ignition with no manual override.
  94.  
  95. I have no problem with using automation, but I object to automation 
  96. limiting my options.
  97. -- 
  98. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  99. Phone: (317)494-6054
  100. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  101. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  102.