Calling FORTRAN from C

[Doug Gwyn]

In article <1278 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
>I see this as part of the calling sequence problem.  Certainly, for a 
>Fortran program to call a C program which expects values rather than
>references, the Fortran program must pass the parameters as it knows
>how C expects to find them.  This might involve considerable work with
>complicated data structures, but presumably these matters are problems
>of the language and not of the implementation.

Woo, woo, let's also insist on a LISP compatible interface.

Let's also make C set up the run-time I/O support, activation contexts,
garbage collection, etc. needed by other languages just in case we use
them..

>I have used several operating systems before UNIX.  On all of them, a name
>was a name was a name.  The program cards and subroutine cards in Fortran
>produced names in the object file identical to what appeared on the card.
>Entry names and COMMON block names likewise.  Assembler-produced programs
>did the same thing.  If I was going to use an Algol program it would still
>be the same.  The calling sequence was a problem, even between Fortrans.
>But not the names.

I don't suppose you ever named any of your functions Q8Q...?

Name clashes among external identifiers has been a practical problem
ever since the invention of the link editor.

UNIX had several constraints that caused the external name mapping
conventions that it had.  One of them was a pre-existing assembler
that had no way to prevent names such as "r0" the register from being
confused with "r0" the external datum.  This caused the C compiler to
give external identifiers an unmistakable form.  When preexisting
assembly code was not an issue, as with the 3B series, the opposite
approach of giving registers etc. unique name formats such as "%0"
was followed and external identifiers were left alone.

C and Fortran external identifiers could not be mixed (such as in
implementing Fortran run-time support in C), due to differences in
behavior expected for the same names.  For example, SUBROUTINE FOPEN.

>Speaking of names, why should one not be able to name a main program?

Why add unnecessary complexity?