Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!dg!rec From: rec@dg.dg.com (Robert Cousins) Newsgroups: comp.arch Subject: Re: Criteria for comparing RISC processors Message-ID: <155@dg.dg.com> Date: 3 May 89 13:05:55 GMT References: <2368@ogccse.ogc.edu> <1464@cfa.cfa.harvard.EDU> <141@dg.dg.com> <18120@winchester.mips.COM> <144@dg.dg.com> <18316@winchester.mips.COM> <147@dg.dg.com> <18653@winchester.mips.COM> Reply-To: rec@dg.UUCP (Robert Cousins) Organization: Data General, Westboro, MA. Lines: 56 In article <18653@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >..... > >>The OCS is a seperate document with specific hooks for Ada, PL/I, etc. >>It deals with not only the extended/nested symbol table issues but also >>attempts to deal with the other known problems as mentioned by all of the >>88/Open members. The collective experience and knowledge of the 88/Open >>group is substantial. >Is this a published document? Yes, contact Anne Marie Larking at Motorola (512)891-3160 for the latest draft. >>on compilers from day one. I believe that it is clear, that this >>competitive situation, with a published standard as reference, has resulted >>in excellent compilers, very quickly. Note that compilers for the 88K >>produce code RIGHT NOW with performance (Mhz for Mhz) equal to the MIPS >-----------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>compiler, which has been in development for years. > >The statement above is a) clear, b) definite, and c) VERY strong. >Unlike much of the rest of the discussion (process X is better than >process Y for getting compilers), this statement is at least testable. > >How about publishing some DATA to back this up? Read MIPS magazine from April where the 88K went head to head with the 3100 and won based upon their full set of benchmarks. MIPS plans to follow up on this with detailed information in another article. We can banter back and forth about what are reasonable measures and what aren't but the bottom line is that an independent and objective organization with a good reputation has compared the two products and has published results which agree with my statement above. (And those benchmarks were run with a compiler now outdated.) Just as benchmarks are used between hardware manufacturers, they are used between compiler vendors. Universally, the losing compiler vendors claim some optimization is "unfair" and then usually adopt it in the next pass. Who wins? The consumer. Who loses? The bad compiler vendor. So, I reiterate my point: compilers produced in a competitive environment will mould their features and performance to the needs of the consumers. For those people who want fast compiles, there will probably be some company which can compile code at very high speeds (and potentially produce poor code). For those who desire the last ounce of performance there will be yet a different product. Lastly for those who want to minimize space there may be a third. There are already several good C compilers for the 88K and this number will only grow over the next years. >-- >-john mashey DISCLAIMER: Robert Cousins Speaking for myself alone.