🚀 go-pugleaf

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: <generic disclaimer, I speak for me only, etc>
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