home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sgi / 12497 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  3.4 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!mips!suneel
  2. From: suneel@mips.com (Suneel Jain)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: R4000 compiler directive, is there one ???
  5. Message-ID: <l8vqdsINNirj@spim.mips.com>
  6. Date: 17 Aug 92 18:02:36 GMT
  7. References: <oisl0q0@zuni.esd.sgi.com> <1992Aug16.210505.18316@megatek.uucp>
  8. Organization: MIPS Computer Systems, Sunnyvale, California
  9. Lines: 63
  10. NNTP-Posting-Host: limca.mips.com
  11.  
  12. In article <1992Aug16.210505.18316@megatek.uucp> rgs@megatek.uucp (Rusty Sanders) writes:
  13. >From article <oisl0q0@zuni.esd.sgi.com>, by olson@anchor.esd.sgi.com (Dave Olson):
  14. >> In <1992Aug14.180101.14529@megatek.uucp> rgs@megatek.uucp (Rusty Sanders) writes:
  15. >> | Net result; if you're using floating point on an R4000 you probably
  16. >> | should use -mips2 -r4000 to get best performance. Does MIPS/SGI
  17. >> | actually support (i.e. accept bug report calls) on the undocumented
  18. >> | -r4000 switch?
  19. >> 
  20. >> I don't think so.  If so, we would have used it in the specmark
  21. >> tests, more than likely.  I don't know why it isn't supported;
  22. >> it may be for lack of testing, or introduction of bugs.
  23. >
  24. >It's my understanding that MIPS specifically did NOT want to use
  25. >code optimized specifically for the R4000 in the Specmark suite.
  26. >To wit: I believe the code wasn't even compiled -mips2 (which
  27. >is clearly supported), much less with -r4000.
  28. >
  29. >I have been lead to believe this is because MIPS wanted to
  30. >accurately represent processor performance with code compiled
  31. >to run on any MIPS machine, hence the -mips1 compile switch.
  32.  
  33. I don't think the above is true. The SPEC numbers released by SGI for
  34. Crimson and R4000 Indigo used the -mips2 option. 
  35.  
  36. >
  37. >I don't believe I've ever seen Specmark numbers for an R4000
  38. >with the code compiled -mips2 -r4000, or even just -mips2
  39. >(although I would dearly love to).
  40. >
  41. >One would think it prudent marketing for MIPS/SGI to release
  42. >both sets of numbers. One for compatibility mode (useful for
  43. >software houses, which will compile -mips1), and one for raw
  44. >"fast as we can get it" mode, which is the most useful number
  45. >for the embedded market and end-users. Not that Spec is terribly
  46. >useful as a performance indicator in the embedded market, but
  47. >it would make my discussions with management SO much easier.
  48.  
  49.  
  50. The -r4000 option is fully supported in the 3.10 release of the MIPS 
  51. compilers. The SPEC numbers released for the Magnum R4000PC used the 
  52. -mips2 and the -r4000 options.
  53.  
  54. Currently, the processors based on the MIPS architecture that are out in 
  55. the market are R3000, R4000 and the R6000. Some time in the future, these 
  56. will be joined by TFP, T5, VRX, ....  
  57.  
  58. There are differences in the instruction scheduling rules for each of 
  59. these processors. Some of the differences are minor, but some are major,
  60. especially in the area of FP scheduling. Most software applications will
  61. be compiled only one way that allows it to run on all MIPS architecture 
  62. boxes.  That lowest common denominator option today is -mips1. Sometime 
  63. in the future, the lowest common denominator option maybe "-mips2" or
  64. maybe even  "-mips2 -r4000".
  65.  
  66. At the same time, there are some programs that want the best scheduling 
  67. for a particular target. To address such needs, we have added the -r4000 
  68. and -r6000 options to the 3.10 compiler. These are completely orthogonal  
  69. to the -mips[1,2,3] options, which define the instruction set to be used.
  70. -- 
  71. Suneel Jain 
  72.  
  73. EMAIL :    suneel@mips.com 
  74. USMAIL:    Silicon Graphics, Inc., 928 Arques Avenue, Sunnyvale CA 94088-3650.
  75.