Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!ames!oliveb!apple!versatc!mips!synthesis!len From: len@synthesis.Synthesis.COM (Len Lattanzi) Newsgroups: comp.arch Subject: Re: Criteria for comparing RISC processors Message-ID: <18645@mips.mips.COM> Date: 2 May 89 07:47:43 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> Sender: news@mips.COM Reply-To: len@synthesis.synthesis.com (Len Lattanzi) Organization: Synthesis Software Solutions Inc, Sunnyvale, CA Lines: 115 In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: :In article <18316@winchester.mips.COM> mash@mips.COM (John Mashey) writes: :>In article <144@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: :>..... :>>be met. And compilers from multiple companies can be intermixed -- :>>even across the language spectrum. :> :>Uh. Sorry, but there are standard calling sequences for both MIPS, and SPARC, :>at least, and have been for a quite a while, and they came into existence :>with the chips, or actually, well before chips existed. : :Last time I heard, there were few if any third party compilers for MIPS :which gives you the ability to totally control the interoperability of :languages. I hope all your third party compilers support the same command line functions and functionality. One of the nice things about have a core set of compilers on the mips chip is that system("cc/as/ld") works regardless of where I'm running on a MIPS, SGI 4D or DECstation. The Micro Focus Cobol Compiler uses the MIPS calling sequence defined in Kane's MIPS R2000 book and C/Cobol call each other with ease. : :>The point was that things like standard calling conventions and object :>formats are just the starting points. : :Agreed. The calling sequence is just the beginning. You also need :symbol management, data structure format and alignment standards, OS :interface standards, side effect definitions and many other things so :that all vendors can take advantage of the entire environment. : :>Then the work begins, and it takes :>years to really get the full act together, if you want to do: :> more than C & FORTRAN :> mixtures of languages :> big programs :> solid exception-handling :> debug the various combinations well, and efficiently : :Actually, not quite. If these features are being retrofitted into :a system, yes, it can take a long time. If, however, the plan is :to support these from the outset, the learning curve is not so steep. : :>I took a look at the 88K BCS recently, and due to lack of time I didn't :>notice it, but I couldn't find things that specifically addressed issues that :>arise with Ada, PL/1, etc [which doesn't mean they're not there, just that :>I didn't see them]. Could you point me at the right places to look? : :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. : :>From experience, I observe: :> 1) from when C works, it's a while until the others work. : :Yes, this difficulty is common, if you are not specifically driving for :multilanguage interoperability from the beginning (which was not done on :early CISC processors either). : :> 2) From when an FPU is perfect, it can take a while until all of :> the FP libraries, exception-handling, etc, is really well wrung-out, :> because it takes running lots of real, large, heavy-duty FP code :> to track down the odd corners. : :Actually, this difficulty arises only if you have just one company doing :the compilers. You say tomato, I say... We'll have to see if Survival of the fittest 3rd party compiler will produce better results than a compiler group that is part of the design process at Mips. Whose 3rd party OS is available for the AViion? : :> 3) From when C works, it can take YEARS of work to make the harder :> combinations of all this be solid. [We're still certainly fixing and :> improving things, even though we could generate optimized code :> for C & Pascal in 1985.] : :Again, it takes this long to shake out the bugs ONLY when you have just :one company writing the software. I'm sure you would agree that (at :the beginning) there was only one small group writing compilers for the :MIPS processor. In the Sparc and 88K worlds, multiple companies worked :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. : Care to quote FORTRAN performance numbers? :>Anyway, this is not to knock the 88K BCS, which is a very reasonable effort, :>merely to observe that it's the first step on a road that's longer, and twistier :>than you might think.... :>-- :>-john mashey DISCLAIMER: : :Actually, it is difficult to unilaterally solve all of the problems in :interoperability. However, when a group of motivated experts from :numerous companies sit down to solve the problems, it is amazing the :progress which can be made. The 88K world is amazingly unified in its :desire to ensure that programming the 88K remains an easy task and to :this end, the entire 88/Open world is carefully working to guarantee :interoperability with not only their own products, but everyone else's. : :Robert Cousins :Dept. Mgr, Workstation Dev't : :Speaking for myself alone. Len Lattanzi (len@Synthesis.com) <{ames,pyramid,decwrl}!mips!synthesis!len> Synthesis Software Solutions, Inc. The RISC Software Company I would have put a disclaimer here but I already posted the article.