🚀 go-pugleaf

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

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.