home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8334 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  2.9 KB

  1. Xref: sparky comp.arch:8334 comp.lang.misc:2702
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!swrinde!mips!spool.mu.edu!news.cs.indiana.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  3. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: MVC and MVCL (was Re: RISC Mainframe)
  6. Message-ID: <55124@mentor.cc.purdue.edu>
  7. Date: 26 Jul 92 18:17:41 GMT
  8. References: <1992Jul19.212901.8857@bcars64a.bnr.ca> <GLEW.92Jul20084651@pdx007.intel.com> <1992Jul20.154604.12548@bcars64a.bnr.ca>
  9. Sender: news@mentor.cc.purdue.edu
  10. Followup-To: comp.arch
  11. Organization: Purdue University Statistics Department
  12. Lines: 45
  13.  
  14. In article <1992Jul20.154604.12548@bcars64a.bnr.ca> schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
  15. >In article <GLEW.92Jul20084651@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
  16.  
  17. >>    >[Henry Spencer]
  18. >>    >Of course, a RISC bigot like me :-) would say that this means your machine
  19. >>    >is unbalanced:  the hardware has useful capabilities that the software is
  20. >>    >unable to exploit in a general-purpose way.  A straight byte-for-byte copy
  21. >>    >is not the only thing one might want to do at top speed...
  22.  
  23. >>    [Stanley Chow]
  24. >>    Ah, I see you belong to the rewrite-code-for-each-new-machine school
  25. >>    of programming. Otherwise, how do you write optimal loops that depend
  26. >>    on the cache line transfer size?
  27.  
  28. >>Playing both sides, it is rather easy to create programs to find
  29. >>and generate the optimal loops automatically.
  30.  
  31. >Clearly then, you belong to the compile-code-for-each-different-machine
  32. >school of administration. I think I will start a disk drive company to
  33. >supply your disk requirements :-)
  34.  
  35. Until there is a language which is powerful enough that the compiler 
  36. can look at all the manifold ways to do what should be done, it is 
  37. necessary to even write code for each different machine.  Certainly,
  38. a compiler should make a different translation of HLL code into 
  39. machine instructions for each different machine.  
  40.  
  41. Now how should the code be written?  If the language can say, copy
  42. this block of memory to there, one can hope that the compiler can
  43. do things in a reasonably optimal manner.  If the language cannot,
  44. then not only should the code be compiled separately, but it should
  45. be written separately.
  46.  
  47. None of the common current HLLs is anywhere near powerful enough to do
  48. this, and other even essentially machine independent constructs, in
  49. such a way that reasonable optimizing can be done.  That is, unless
  50. you allow the compiler to do such rash things as to say that "this is
  51. what the user MEANT to do."  And if the user does something slightly
  52. different in between, the resulting code does not even accomplish the
  53. design goals, however inefficiently.
  54. -- 
  55. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  56. Phone: (317)494-6054
  57. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  58. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  59.