History of High Performance Computing in Cambridge

Cambridge-Cranfield HPCF  > Information for Users  > Programming and Compilation  > Mixed Language

Mixed language programming is often a very appropriate way of combining the strengths (or avoiding the weaknesses) of various programming languages. For the purposes of this document, it also covers mixed language programming through calling third-party, e.g. calling NAG libraries (written in Fortran) from C.

There follow some brief comments on mixed language programming on the HPCF. Except where otherwise noted, C++ can be read for C, and Fortran90 for Fortran, but be warned that this applies only to the language subset that is common between C and C++, and between Fortran 77 and 90.

This document is divided into the following sections:

• Calling system services
• Why do it?
• General comments, applicable to most systems
• NAG and BLAS from C

---

Calling system services

On Unix systems, the language for which the system interface is defined is C; most vendors provide a collection of extra system interface functions for Fortran, but they are different between every system, and often each vendor's compiler on a system. However, it is usually easier to edit your code to use these than to write your own functions in C.

To find them for hartree, look in the XL Fortran 7.1 Chapter 10 Interlanguage Calls available in the IBM manuals section of these Web pages.

To find them for hodgkin, use the insight command on hodgkin, select SGI Developer and look in the MIPSpro Fortran 77 Programmer's Guide. You will usually have to specify the extra library -ffio.

If the function that you need is not available, you need to call a library not available from your chosen language, or you are importing mixed language code, you will need to read further.

Why do it?

No one language is perfect for all programming problems. Of the four main languages available (Fortran 77, Fortran 90, C, C++), C++ offers the most sophisticated object-oriented approach, whereas Fortran offer simplicity and speed. It is necessary to consider the choice of language before starting on a programming project, and sometimes no one language is suitable for the whole project, and then a mixed language solution can be best.

General comments

Mixed language programming is conceptually simple when the languages share common concepts, but the devil is in the details. It is also a technique which, at some level, is extremely common. Whenever a Fortran program does any I/O it calls, via libraries, the underlying operating system, which is usually written in C, and never entirely in Fortran.

It is generally a bad idea to mix I/O to the same stream between two languages, though writing complete lines to stdout and Fortran's default output unit (i.e. '*') usually works. And care should be taken with allocating memory, especially when using C++ or Fortran 90, to avoid the different language's memory allocators getting confused. And such things as longjmp should never be used.

It would be possible to write a generic description of this area, but it would be long and complicated, so the following description applies to babbage and hodgkin only, but assumes that you are writing code that you may want to port to other systems later. The general points which need to be considered when trying to link Fortran and C on the HPCF are:

• Subprogram and common block names: on hodgkin, they are forced to lowercase and have an underscore appended. [*]
• C++ performs some additional name mangling, and it is necessary to suppress this explicitly when linking with another language.
• Argument passing: Fortran arguments are passed by pointer to their location. [*]
• Character arguments: C uses null termination, Fortran passes the length in a hidden argument. This is an int (not a pointer to an int), and follows the main argument list, with one per string passed, in the order that the strings are passed. [*]
• Multidimensional arrays: in both Fortran and C these are pointers to the first actual element, and are stored in a contiguous block, but the effective order of subscripts is reversed.
• Character functions: there are two extra initial arguments, as C sees the call, containing a pointer to where to store the result and the length of the result. [*]
• Complex data and functions: Fortran COMPLEX*16 is handled exactly like struct {double re, im;}, including as the return type of functions.[*]
• Fortran 90 derived types: avoid these if you possibly can, as their handling is very system dependent and rarely documented.
• The final linking: if done by cc (in which case main must be in C), extra Fortran libraries will need to be specified. Fortran main programs can be linked using cc, but you don't want to know how - seek advice if you have to.
• Fortran may require an additional run-time environment to be constructed by calling system-dependent functions.
• I/O buffering: if both C and Fortran write to stdout, the order of the output may be surprising unless C calls fflush before returning to or calling Fortran, or line buffering is selected using setvbuf.

[*] The above describes the most common implementation strategies, but there are systems around where other variants are used. Note that, despite common belief, the Fortran standard does not require arguments to be passed by reference.

---

NAG and BLAS from C

The interface routines in the NAG and BLAS libraries are written to Fortran conventions; to call these libraries from C, all arguments must be passed as pointers. On hodgkin, one may specify -lblas to use just SGI's BLAS routines, or -lnag -lblas to use NAG, as NAG uses the vendor-supplied BLAS.

There is the usual NAG documentation on the HPCF: both nag_help (text interface) and nag_info (X interface).