Xref: utzoo comp.lang.c:18630 comp.lang.fortran:2033
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!texsun!sun-barr!rutgers!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!ka
From: ka@june.cs.washington.edu (Kenneth Almquist)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: Calling FORTRAN from C (Was: Need matrix inversion C routine).
Summary: How about using a stub generator?
Message-ID: <8197@june.cs.washington.edu>
Date: 12 May 89 10:33:20 GMT
References: <2846@tank.uchicago.edu> <5785@cbnews.ATT.COM> <10087@smoke.BRL.MIL> <17333@mimsy.UUCP>
Organization: U of Washington, Computer Science, Seattle
Lines: 43

The problem of differing calling conventions could be solved with a
stub generator.  Say you had a FORTRAN subroutine that you wanted to
call from C.  The input to the stub generator would include the name
of the FORTRAN routine, the types of its arguments, the name that the
routine was to be know from in C, and the types of the arguments to
be passed from C.  The output of the stub generator would be a C
callable routine which would convert the arguments to the appropriate
types for C (if necessary), run the FORTRAN routine, and finally
convert the resulting values back to the appropriate types for C
(again only if necessary).

The advantages of this approach are:

1)  The language standards don't have to change.  Instead, all that
is required is to develop a new standard for the stub specification
language.  So there is no need to convince the existing standards
committees to address the interlanguage communication problem.  They
haven't addressed it in the past, and there is no reason to expect
this to change in the near future.

2)  Another advantage is that existing compilers probably don't have
to change (see below).  If you own a C compiler and a FORTRAN compiler
for an IBM/PC compatible, the chances that the same company will have
written both compilers is relatively small.  Either of these companies
may have decided that being compatible with their competitor's compilers
is not worth the trouble.  On the other hand, a third party might be
willing to sell a stub generator that was compatible with both.

3)  The number of people who are interested in interlanguage communi-
cation is probably fairly small, and compiler writers might be hesitant
to add features that they think will be only used by a few of their
customers.  On the other hand, stub generators are relatively easy to
write, so a company might be willing to market a stub generator to a
much smaller market than a compiler company would target.  Alternatively,
users could write their own.

This does not address the issue of compatible run time systems.  Both
FORTRAN and C have relatively simple run time systems, so incompatibility
is not likely to be a major problem in this case.  The standard would
have to give standard names to the initialization and cleanup entry
points for the run time systems, so that a program with a C main routine
could initialize the FORTRAN run time system, and vice versa.
				Kenneth Almquist