Xref: utzoo comp.lang.fortran:3642 comp.lang.misc:5388
Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mailrus!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.fortran,comp.lang.misc
Subject: Re: What is the FORTRAN for ?
Summary: The versatility at the compiler level would not be expensive
Message-ID: <2453@l.cc.purdue.edu>
Date: 19 Aug 90 13:17:46 GMT
References: <13035@mentor.cc.purdue.edu> <60344@lanl.gov> <13071@mentor.cc.purdue.edu>
Followup-To: comp.lang.fortran,comp.lang.misc
Organization: Purdue University Statistics Department
Lines: 48

In article <13071@mentor.cc.purdue.edu>, ags@seaman.cc.purdue.edu (Dave Seaman) writes:
> 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.

There is a not too expensive alternative to this problem, and other interface
problems.  That is, to put the necessary software to handle various call and
return procedures in the various compilers.  Each compiler expects its 
input arguments in a clearly defined manner, and also its register saving
procedures, and there is no good reason why this information could not be
incorporated into another compiler.  This could even be used for machine
language calls.

I did not say that there were no costs, in particular efficiency costs, 
involved.  But it provides a kludge which is easy to implement.  It also
gets around the problems of name changes by the compiler in many cases.
In the UNIX systems I have seen, in general a Fortran program cannot call
a C program because of the name problem.  

It may be necessary to produce these interfaces in assembler, but this will
be a small cost compared to the alternatives of language translation or
recompilation.  Many algorithme at Purdue were not callable from one Fortran
to another, and this could have been handled.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)