Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.fortran
Subject: Re: Calling FORTRAN from C (Was: Need matrix inversion C routine).
Summary: Why have two sets of libraries?
Message-ID: <1280@l.cc.purdue.edu>
Date: 3 May 89 19:47:30 GMT
References: <2846@tank.uchicago.edu> <5785@cbnews.ATT.COM> <10087@smoke.BRL.MIL> <12661@ut-emx.UUCP>
Organization: Purdue University Statistics Department
Lines: 30

In article <12661@ut-emx.UUCP>, cccm001@ut-emx.UUCP (Tom Linsley) writes:
> In article <1274@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
< > 
< > This can even be a problem with ONE language.  Programs in Fortran
< > compiled with one calling sequence on the CDC 6x00 could not call programs
< > written in the other with arguments, and so there was a problem with the use
< > of library routines.  Neither was ever implemented, and the machines have
< > been phased out.
> 
> I'm not quite sure what you mean by this last sentence.  The mutual
> incompatibility between the RUN and FTN calling conventions was
> certainly an annoyance, but was hardly insurmountable if one were willing
> to have two (or more) sets of libraries.  These were not the only
> incompatibilities among compilers for this equipment, differences in I/O
> support routines prevented mixing object modules of some Fortran
> compilers using the same linkage mechanism.

I see no reason to have two sets of libraries.  This is a possible solution,
and if the use of the two calling sequences was envisioned when I produced
my random number package for our machines, it would have been done that way.
However, converting from the RUN sequence to the FTN sequence later turned
out to be just too difficult.  If I needed a production run from a FTN
sequence compiler, or if it were necessary to use the FTN library, I would
have put in a simple jacket to convert the FTN call to a RUN call.  The
other way would have been more difficult, but still could be handled by
a machine-language override call.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)