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: <147@dg.dg.com> Date: 1 May 89 14:14:25 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> Reply-To: rec@dg.UUCP (Robert Cousins) Organization: Data General, Westboro, MA. Lines: 97 In article <18316@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >In article <144@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >..... >>The real issue here is no so much one of compilers, however, but of >>the actual object code produced and used on a given system. The 88K >>OCS (Object compatibility standard) addresses most of these issues and >>is designed to provide extensibility so that future requirements can >>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. >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. > 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. >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.