B Rationale for Mixed Language Programming

Starlink has historically been a “FORTRAN only” project. There are several reasons for this. Primarily it is because scientists have been brought up with FORTRAN and for most purposes it is perfectly adequate for our needs. However, there are some tasks for which FORTRAN is not really suitable. In such situations it may be better to write programs in a language other than FORTRAN, rather than try to persuade FORTRAN to do something that it is not suited to. Writing recursive procedures is the classic example, but there are many more. Starlink has recognised the need for a language other than FORTRAN by providing C compilers at all Starlink nodes.

There are in fact good reasons to avoid diversifying into trendy new languages unless it is absolutely necessary. Any substantial piece of software will require someone to support it long after the original author has moved on to other things and it is not reasonable to expect that person to have expertise in a large number of programming languages. However, for some purposes, FORTRAN 77 is simply not adequate. In fact some major parts of Starlink software have been written in other languages because of this. HDS. (See SUN/92.) is written in C (it was originally written in Bliss, in the days when even C was impractical because of restrictions in the early compilers). In the future, FORTRAN 90 will overcome many of the limitations that FORTRAN 77 has but, until that becomes readily available (and even after), some things are simply better written in C.

It is often the case that most of a program can be written in FORTRAN, leaving only a few tricky parts that cannot be written using standard (or even non standard) FORTRAN. An example of a task that cannot be performed using standard FORTRAN is getting some memory for use in your program. Admittedly, there are often system service subroutines available but these are virtually guaranteed to be non portable to other computers. Often a better approach is to write the tricky parts in C. This is exactly the approach that has been adopted for HDS. The problem then is how to pass data between FORTRAN routines and C functions. This document will describe how to do this. Clearly the details of passing information between program segments written in different languages will be machine dependent; however, there are also many important similarities. Despite any problems that may arise, it is easier to port programs written in a mixture of FORTRAN and C to other computer systems than to port programs written purely in FORTRAN that make use of machine-specific routines for system services.

How to mix FORTRAN and C in a way that is portable to all current Starlink hardware is described in

Sections 5 and 8.

It is quite likely that you will often want to use C to make use of something that the C run time library provides, such as allocating memory. This requirement is sufficiently common that a library of FORTRAN callable routines has already been provided to do exactly that. It is called PSX and is described in SUN/121. In many programs, use of the PSX library will remove the need to write any C code at all.

You may think that if you want to use C for part of a program then you should use C for all of the program. This may indeed be the best option; however, if you also want to call subroutines that are written in FORTRAN (e.g. just about any Starlink library), then you are going to be involved in mixed language programming anyway. The correct choice will depend on the circumstances.

Writing mixed language programs is not something that should be embarked upon lightly. There might be a better way of achieving the same result using just FORTRAN. The source code may not look as pretty, but if it runs effectively and efficiently then that is all that is required. If you can achieve what you want using standard FORTRAN then you should do so. If you cannot, then this document will tell you how to mix FORTRAN and C in a portable way. The programming language manuals of the computer manufacturers tell you how to mix languages on their own hardware, but achieving portability needs a little more thought.

Finally, if you are new to C, you should be aware that the way that things are normally done in C can be rather different from the way that they are normally done in FORTRAN. When I was new to C, I proudly showed someone one of my first C programs. “That’s not a C program,” they said, “That’s a FORTRAN program that’s written in C.” They were, of course, right. A useful book an C programming is Banahan [3]. This describes how to write programs in ANSI standard C and is written in an easy-going style. The author is not averse to criticizing C when he thinks that a feature of the language is not appropriate.