home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8444 < prev    next >
Encoding:
Text File  |  1992-07-29  |  4.0 KB  |  86 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!menudo.uh.edu!sugar!ficc!peter
  3. From: peter@ferranti.com (Peter da Silva)
  4. Subject: Re: CISC Microcode (was Re: RISC Mainframe)
  5. Message-ID: <id.GQWR.83D@ferranti.com>
  6. Organization: Xenix Support, FICC
  7. References: <55117@mentor.cc.purdue.edu> <id.RKUR.GFF@ferranti.com> <55294@mentor.cc.purdue.edu>
  8. Date: Wed, 29 Jul 1992 13:50:04 GMT
  9. Lines: 75
  10.  
  11. In article <55294@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  12. > In article <id.RKUR.GFF@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
  13. > >I'm glad you noticed it. We're agreed then that these idiot savants generate
  14. > >code that is as fast as a human can write, if not the same sort of code. 
  15.  
  16. > This is not always the case.  It is quite possible that a simple idea which
  17. > a human can see is not within the category of those known to the compiler.
  18. > No compiler can change the algorithm to one that it does not know about.
  19. > I can, and do.
  20.  
  21. Yes, I quite agree, different problem spaces demand different algorithms for
  22. solution. However, and this is the key point, it is (in 1992) extremely rare
  23. that you encounter a constraint on the problem space due to the hardware that
  24. has any significant effect on the choice of algorithm. Things like 64K segment
  25. limits, massively parallel hardware, or the absence of a FPU... yes. Things
  26. like the presence or absence of autoincrement addressing... no. It's been many
  27. years that microoptimisation for the instruction set has been cost-effective
  28. outside of tight loops.
  29.  
  30. > >Because allowing the compiler to find machine-specific optimisations is more
  31. > >cost effective than doing it myself. Because the code I write runs on Sparcs,
  32. > >68000s, 80386s, 80286s, VAXen, and 68020s. Because next month it might be
  33. > >running on MIPS or 88000. Next year it might be running on Supersparc or Alpha.
  34. > >Because optimising when you don't need to is a waste of resources.
  35.  
  36. > This means that the language should be expanded to include the alternatives.
  37.  
  38. Why? So I can write the same code half a dozen times? Whether I do so by
  39. coding a loop in five different assembly dialects or by coding a bunch of
  40. alternatives in Herman Rubin's Perfect Language it's still a waste of time.
  41.  
  42. > >> >I expect any good programmer to code for the abstract machine defined for
  43. > >> >the language. Remember, software longa, hardware brevis.
  44.  
  45. > >> This might be reasonable if we had a language produced by people who have
  46. > >> some respect for the capabilities of humans.
  47.  
  48. > >We do. We have dozens of them.
  49.  
  50. > Name one in which recognizes the various things I have previously published
  51. > in a syntax intended for fast use by a human being.
  52.  
  53. The various things you're looking for are in the "tight loop" category, and
  54. the effort of coding them in assembler is negligable compared to the cost of
  55. coding the rest of the program in a language designed for microoptimisation
  56. rather than expression of an algorithm.
  57.  
  58. C++ with embedded assembly and inline expansion.
  59. Forth.
  60. C with inline assembler.
  61. Turbo Pascal.
  62. Dec Fortran 77.
  63. Most modern Lisp dialects.
  64.  
  65. > Lisp seems to have a
  66. > fairly reasonable collection of primitives, but a human being should not 
  67. > be REQUIRED to use clumsy prenex notation.
  68.  
  69. Oddly, many human beings prefer it. HP has managed to remain the last
  70. successful US calculator manufacturer by using a similar notation.
  71.  
  72. > >Analogies are like instant coffee, but what you want is a little more primitive
  73. > >than that. I don't know about you, but I'm glad they don't make cars with
  74. > >manual chokes any more, or that need double-clutching when you shift.
  75.  
  76. > Having had choke problems, I would prefer that cars had manual choke 
  77. > overrides, to be used when necessary.  The only problem I have ever had
  78. > with a manual choke is forgetting to turn it off.
  79.  
  80. Why am I not surprised?
  81. -- 
  82. Peter da Silva                                               `-_-'
  83. $ EDIT/TECO LOVE                                              'U` 
  84. %TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
  85. Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
  86.