The development of MPICH coincided with the emergence of a number of ``64-bit systems.'' Many programmers, remembering the problems moving code from 16- to 32-bit platforms, expressed concern over the problem of porting applications to the 64-bit systems. Our experience with MPICH was that, with some care in using C properly (void * and not int for addresses, for example), there was little problem in porting MPICH from 32- to 64-bit systems. In fact, with the exception discussed below, MPICH has no special code for 32- or 64-bit systems.
The exception is in the Fortran-C interface, and this requires an understanding of the rules of the Fortran 77 Standard. While C makes few statements about the length of datatypes (for example, sizeof(int) and sizeof(float) are unrelated), Fortran defines the ratios of the sizes of the numeric datatypes. Specifically, the sizes of INTEGER and REAL data are the same, and are half the size of DOUBLE PRECISION [15]. This is important in Fortran 77, where there is no memory allocation in the language and programmers often have to reuse data areas for different types of data. Further, using 64-bit IEEE floating point for DOUBLE PRECISION requires that INTEGER be 32 bits. This is true even if sizeof(int) (in C) is 64 bits.
In the Fortran-C interface, this problem appears when we look at the representation of MPI opaque objects. In MPICH, they are pointers; if these are 64 bits in size, then they cannot be stored in a Fortran INTEGER. (If opaque objects were ints, it would not help much; we would still need to convert from a 64-bit to 32-bit integer.) Thus, on systems where addresses are 64 bits and Fortran INTEGERs are shorter, something must be done. The MPICH implementation handles this problem by translating the C pointers to and from small Fortran integers (which represent the index in a table that holds the pointer). This translation is inserted automatically into the Fortran interface code by the Fortran interface generator bfort (discussed in section The Fortran Interface ).
Another problem involves the routine MPI_Address, which returns an ``address'' of an item. This ``address'' may be used in only two ways: relative to another ``address'' from MPI_Address or relative to the ``constant'' MPI_BOTTOM. In C, the obvious implementation is to set MPI_BOTTOM to zero and use something like (long)(char *)ptr to get the address that ptr represents. But in Fortran, the value MPI_BOTTOM is a variable (at a known location). Since all arguments to routines in Fortran are passed by address,Value-result if one must be picky; in practice, the addresses are passed. the best approach is to have the Fortran version of MPI_Address return addresses relative to the address of MPI_BOTTOM. The advantage of this approach is that even when absolute addresses are too large to fit in an INTEGER, in many cases the address relative to a location in the user's program (i.e., MPI_BOTTOM) will fit in an INTEGER. This is the approach used in MPICH; if the address does not fit, an error is returned (of class MPI_ERR_ARG, with an error code indicating that the address won't fit).
As a final step in ensuring portability to 64-bit systems, our configure program runs some programs to determine whether the system is 32 or 64 bits. This allows MPICH to port to unknown systems or to systems like SGI's IRIX that change from 32-bit (IRIX 5) to 64-bit (IRIX 6) without any changes to the code.