Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!mailrus!purdue!mentor.cc.purdue.edu!seaman.cc.purdue.edu!ags
From: ags@seaman.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.fortran
Subject: Re: What is the FORTRAN for ?
Message-ID: <13071@mentor.cc.purdue.edu>
Date: 18 Aug 90 16:10:33 GMT
References: <13035@mentor.cc.purdue.edu> <60344@lanl.gov>
Sender: news@mentor.cc.purdue.edu
Reply-To: ags@seaman.cc.purdue.edu (Dave Seaman)
Organization: Purdue University
Lines: 28

In article <60344@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <13035@mentor.cc.purdue.edu>, by ags@seaman.cc.purdue.edu (Dave Seaman):
>> So what do you do if the target machine has more than one Fortran
>> implementation and the different versions are not even compatible with each
>> other?

>I'm not interested in whether the Fortrans (or Cs, Pascals, Modulas,
>etc.) are compatible with each other, I only want them to be _callable_
>from each other on a way which appears consistent from the HLL point of
>view.  If this means that several different bridges to Fortran have to
>be present on the low-level for different Fortrans, that tough.  Of
>course, implementors who avoid use of industry (or vendor) standard
>calling sequence conventions are shooting themselves in the foot by
>making their produce harder to use from within existing environments.

The two examples I gave of incompatible Fortrans were both cases of
vendor-supplied Fortrans that ran on the same machines and were reasonably
compatible at the source language level (though with slightly different
extensions), but which were fundamentally incompatible at the object code
level.  They are definitely not callable from each other.  

An implementor of some other language (Pascal, say) does not need to support
every incompatible version of Fortran on the machine.  It's more cost-effective
to pick just one Fortran to support.

--
Dave Seaman	  					
ags@seaman.cc.purdue.edu