🚀 go-pugleaf

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: <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.


 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.