🚀 go-pugleaf

In article <1992Jan28.212225.25601@CSD-NewsHost.Stanford.EDU> amorgan@CS.Stanford.EDU (Crunchy Frog) writes:
>Sorry to interrupt the extremely exciting flame war going on, but I have
>a question.  Right now it is rather difficult to combine, say fortran code
>with C, or indeed any language with any other.  This means, for all practical
>purposes, that code must be written in one language only (ignoring cases
>like emacs).  Has any thought been given to the possibility of making the
>GNU language products (when they all come out) able to speak to one another?
>The idea being that I could write some code in C, some in Fortran, some in 
>LISP, compile link and go.  I realize this would be difficult but is it so
>hard that it is not even worth thinking about?

Unfortunately, there are often two incompatible goals when writing
third-party compilers.  You'd like all the compilers to be compatible with
each other, but you would also like the compilers to be compatible with the
existing software on the systems.

So, for instance, a program compiled with GNU C should be able to call
routines in the system's libc, which may have been compiled by the vendor
using some other compiler.  And a program compiled with GNU Fortran should
be able to call routines in the systems libfort.  If the vendor doesn't
have a system-wide calling convention standard, the libc and libfort
libraries might use different calling conventions, and the C and Fortran
compilers would have to generate the appropriate types of calls.

A common extension is to specify the language of an external routine in the
prototype for it.  This informs the compiler that it should use that
language's calling conventions.

-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar