Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!vsi1!wyse!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: Criteria for comparing RISC processors Message-ID: <18316@winchester.mips.COM> Date: 28 Apr 89 20:57:39 GMT References: <2368@ogccse.ogc.edu> <1464@cfa.cfa.harvard.EDU> <141@dg.dg.com> <18120@winchester.mips.COM> <144@dg.dg.com> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 66 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. In fact, there is a standard 88K >calling sequence which the ABI specifies which is supported by the >various compilers. As has been amply pointed out, this is lacking >elsewhere in the industry. Hopefully, the rest of the computing world >will follow our lead to true interoperability. 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. I guess I missed making the point originally, so let me try again. The point was that things like standard calling conventions and object formats are just the starting points. 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 In particular, regular COFF-like symbol tables don't quite make it. 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? From experience, I observe: 1) from when C works, it's a while until the others work. 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. [and remember, MIPS R2000s give precise exceptions for floating-point, which makes them one of the easier cases, in some sense...] 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.] Before claiming the lead in operability, I'd suggest that passing a couple milestones would help believability: 1) Production systems (including FP), in end-users' hands. 2) Any commercial Spice in end-user's hands (this is always a useful test for FORTRAN & FP in general). 3) ISV Compile, link, and debug (without programmers going crazy) something like (for example) million-line {PL/1 or FORTRAN, or Ada} programs mixed with C and assembler, and put the result in end-user production use. 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: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086