Data Gathering and Analysis | Unix Application Migration Guide (Patterns & Practices)

When you migrate Fortran code, you need to gather a range of data so that youcan determine the best migration approach. The data that you need to collect includes the following:

The Fortran level (77, 90, or 95) used
The graphical user interface (GUI) requirements
Any required third-party libraries
Whether the application provides any cross-language support
The best development and build environment to use for the migration

You need to know how your Fortran code is being used, for example:

Is it a stand-alone application?
Does it expose interfaces for other languages?
Does it call interfaces in other languages?

Fortran is commonly used in computationally intensive applications. Often this means that Fortran is used in loosely coupled , high performance grid computing environments. Typically, distributed grid computing requires integration with dynamic scheduling and high performance message passing. In most cases, Fortran modules are not part of the core infrastructure services, so they need to integrate with libraries that perform these functions.

It is also important to understand the target development environment for the Fortran migration. Possible target environments include:

Migration of the development environment from UNIX to Windows and Microsoft Win32 .
Continued development on UNIX with Windows as a cross-platform port.
Migration of the development environment from UNIX to a UNIX style development environment on Windows, such as Microsoft Interix.

The preceding considerations need to be addressed, along with the actual source code migration.

Using Third-Party Libraries

Fortran modules can call or be called by other languages, in addition to runningas stand-alone modules. When Fortran is integrated with other languages, it is important to understand the naming and calling conventions used because theycan have a big impact on the migration.

The necessity to address differences in calling conventions between Fortran andC/C++ is not unique to a migration from UNIX to Windows. The Windows platform offers a wide range of third-party libraries to perform functions that could eliminate the need of some of the UNIX-based custom code. The use of these types of third-party C/C++ libraries in Windows eases the overall migration task, and is an advantage in migrating to Windows.

This section focuses on integrating Fortran with C and C++ libraries in the Win32 subsystem. It begins by examining the default calling and naming conventions for Fortran and how these conventions work with typical Win32 C and C++ libraries, and with Win32 APIs. Table 14.1 lists the defaults calling and naming conventions for Fortran, C/C++, and Win32 APIs.

Table 14.1: Fortran, C/C++, and Win32 Calling and Naming Conventions
Source Type	Arguments	Procedure Case	Stack Cleanup	Argument Suffix
Fortran	By reference	Procedure name in all uppercase	The procedure being called is responsible for removing arguments from the stack before returning to the caller.	Yes
C/C++	By value	Procedure name in all lowercase	The procedure doing the call is responsible for removing arguments from the stack after the call is over.	No
Win32 API ( STDCALL )	By value	Procedure name in all lowercase	The procedure being called is responsible for removing arguments from the stack before returning to the caller.	Yes

During a migration, a developer usually encounters both the C/C++ calling convention and the STDCALL convention. Some of the common development libraries can take care of some of the differences in calling conventions. Other libraries require explicit declarations.

Differences in calling conventions can be handled in a number of ways, including the use of:

The Fortran Interface statement
C function declarations
Compatibility layers
Modular code that uses Fortran libraries

These are explained in the next four sections.

The Fortran Interface Statement

You can use the Fortran Interface statement to transform Fortran calling conventions into C style conventions. The following example takes a call to the C function CLibFunction , which calls a C function that passes an integer value. An alias attribute is used to take care of the case difference and extra underscore .

 INTERFACE  SUBROUTINE CLIBFUNCTION(I)      !MS$ATTRIBUTES C, ALIAS:_CLibFunction :: CLIBFUNCTION       INTEGER I  END SUBROUTINE CLIBFUNCTION END INTERFACE

Attributes can be defined with the Interface statement to adjust the Fortran calling conventions so that they match existing C libraries.

C Function Declarations

You can also use a combination of C function declarations, function naming, and argument definitions to resolve calling convention differences. The following example shows how a STDCALL function declaration handles stack calling conventions and suffixes in a manner similar to default Fortran conventions:

 extern "C" void __stdcall FLIBUNCTION (int n);

This type of translation is especially useful when dealing with C++ name mangling (where the compiler adds characters to function names ). Implementing the STDCALL convention tells the compiler that this function is not subject to C++ name mangling.

Compatibility Layers

Another means of resolving calling convention differences is to use a compatibility layer to translate between Fortran and C/C++. Using this approach, C/C++ libraries could expose STDCALL type interfaces, while actually calling the C/C++ routines using C calling conventions.

The strategy you use for third-party library integration also depends on whether the Fortran or C/C++ code can be modified. For example, introducing Fortran Interface statements is only a viable option if the developer can modify the Fortran source code. The same is true regarding changing the function declarations in C/C++ source code.

This makes the concept of a compatibility layer the most flexible solution. However, this solution requires that you develop and maintain additional source code.

Fortran Modules

As with most languages, modularity allows for easier cross-platform development. Because Fortran is most often used for high perform computations , platform-specific routines may already exist in external, non-Fortran routines.

Even though Fortran is often isolated to computationally specific routines, platform-specific APIs ” such as threading, synchronization, and GUI functions ” can also be used in Fortran. The Windows APIs for threading, synchronization, and GUI functions are typically made available using Fortran modules.

For example, Fortran modules could exist for Windows GUI functions, threading, and OpenGL graphics. The Fortran modules encapsulate the C and STDCALL style functions to the Windows kernel and Win32 libraries. To enhance portability, platform-specific code should either be encapsulated in Fortran modules, or througha call layer to C and C++ functions.

The Fortran module feature requires a Fortran 90 or later compiler.

Fortran GUI applications often use OpenGL for high-performance graphics. OpenGL provides a cross-platform API for GUI development with minimal platform-specific code requirements. On Windows, OpenGL is a C library, and can be used either from a Fortran module, or through a custom OpenGL GUI extraction layer.

Your migration choice will largely depend on whether the existing UNIX Fortran application extracts the GUI calls or uses a Fortran module. Either strategy can be migrated to Windows.

Integrating Fortran with POSIX Applications

The Fortran application that you are migrating may be required to integrate with other POSIX-style applications. In this situation, the target Windows environment can be either the Windows POSIX subsystem (Interix), or a UNIX emulator running on the Win32 subsystem. Microsoft Interix is the full-featured POSIX subsystem on Windows. MKS NuTCRACKER and Cygwin are examples of UNIX emulators.

The Fortran considerations for using either the Interix POSIX subsystem or a UNIX emulator are the same as for C/C++ migrations.

Note	As of the time of publication, the GNU Fortran 77 compiler, f77 , is the only Fortran compiler available for Interix.