home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8178 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.8 KB
  1. Path: sparky!uunet!spool.mu.edu!news.nd.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: <54638@mentor.cc.purdue.edu>
  6. Date: 21 Jul 92 13:10:48 GMT
  7. Article-I.D.: mentor.54638
  8. References: <TOM.92Jul13121539@amber.ssd.csd.harris.com> <1992Jul20.205209.28863@boole.uucp> <l6mlr0INN7tu@spim.mips.com>
  9. Sender: news@mentor.cc.purdue.edu
  10. Organization: Purdue University Statistics Department
  11. Lines: 52
  12.  
  13. In article <l6mlr0INN7tu@spim.mips.com> mash@mips.com (John Mashey) writes:
  14. >In article <1992Jul20.205209.28863@boole.uucp> John@boole.uucp (John Ahlstrom) writes:
  15.  
  16. >>Did anyone at work do a study of the utility of address modes independent 
  17. >>of the speed of any particular implementation of them?  I doubt that an
  18. >>ex post study of the implementated speed of modes is a good way to 
  19. >>decide which ones are valuable to have.  Valuable to use in a give
  20. >>compiler perhaps, but not valuable to have in an architecture.
  21.  
  22. >There have been plenty of papers that have addressed this over the years,
  23. >usually in the form of:
  24. >    a) Take a given CPU architecture+compiler pair, and analyze the
  25. >    distribution of address modes.
  26.  
  27. The sensibility of this assumes that we have good languages/compilers.
  28.  
  29. >    (Note that this has implicit use of performance, i.e., you might
  30. >    assume that agonizingly-slow modes might be avoided.)
  31. >    On the other hand, if you find modes that are reasonably fast
  32. >    (as fast as any equivalent sequence), and don't get used,
  33. >    either:
  34.  
  35. >        1) The compilers can't figure out how to use them often.
  36.  
  37. We keep hearing that compilers can do as well as humans.  Now if a
  38. human can figure out how to use these modes, don't blame the mode,
  39. blame the compiler if it cannot figure out how to use it efficiently.
  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.  I expect any good programmer to do as
  45. well; I am not a professional programmer.
  46.  
  47. >    Hennessy & patterson have some discussion of this topic.
  48.  
  49. >    b) Of course, simple analysis of existing modes may tell you ones
  50. >    that are not very useful, but they won't point out ones that
  51. >    aren't present in the example, but would be useful.  That is,
  52. >    to decide that auto-increment of some kind might be useful,
  53. >    you have to do more detailed analyses of code sequences to see.
  54.  
  55. In other words, the programmer has to think about using the machine
  56. capabilities, or there has to be in the compiler enough so that the
  57. compiler will try out these capabilities.
  58.  
  59.             ...................
  60. -- 
  61. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  62. Phone: (317)494-6054
  63. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  64. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  65.