Porting Fortran Source Code Between Systems

In general, Visual Fortran is a portable language. One of the main advantages of the language is the availability of large and well-tested libraries of Fortran code. You also might have existing code addressing your problem that you want to reuse. Math and scientific code libraries from most vendors should port to Visual Fortran with virtually no problems.

You might also want to use Visual Fortran as a development platform for code that can later be ported to another Compaq Fortran system, such as mainframe-class Alpha systems running the Compaq Tru64 UNIX, Linux, or Compaq OpenVMS operating system.

Whether you are bringing code from another system or planning to export it to another system, you will need to do the following:

• Isolate system-dependent code into separate modules. Maintain distinct modules with similar functionality for each separate platform.
• In your main program, use only language extensions that will compile on both platforms, putting system-dependent code into modules.
• Place language extension subsets into modules.
• If you use Microsoft compiler directives, replace the older $directive format with the !DEC$ directive format, because this will be ignored by other systems.
• Specify data precision, for integers and logicals as well as for floating-point numbers when the size matters. If you do not explicitly specify KIND for variables, this could be the source of problems if one system uses a default of (KIND=2) for integers, while your program assumes (KIND=4).
• Conversely, if the size of a variable is not significant, avoid specifying data precision. Code that does specify precision will run slower on systems that do not use the same default integer and real sizes.
• Avoid using algorithms that exhibit floating-point instability. For information on handling floating-point numbers, see The Floating-Point Environment.
• Specify equivalent floating-point precision on each platform.
• Specify the appropriate attributes when defining routines and data that will be interacting with code written in Microsoft Visual C/C++ or assembly language.

For more information:

• On porting code between systems, see Portability.
• On compatibility with Compaq Fortran on Alpha platforms, see Compatibility with Compaq Fortran on Other Platforms

Choosing a Language Extension Subset

The Visual Fortran compiler supports extensions used on a variety of platforms, plus some that are specific to Visual Fortran. Because there are Fortran compilers for many different computers, you might need to move your source code from one to another. If the trip is one-way and it is permanent, you can simply change the code to work on the second platform. But if you need to make sure you can move the code where ever it is needed, you must be aware of the extensions to Fortran that are supported on each platform.

You can use some of the Visual Fortran compiler options to help you write portable code. For example, by specifying ANSI/ISO syntax adherence (/stand option) in the Project Settings (Fortran tab) dialog box or on the command line, you can have the compiler enforce Fortran 90 or 95 syntax. Code that compiles cleanly with this option set is very likely to compile cleanly on any other computer with a Fortran compiler that obeys strict Fortran syntax.

If you choose to use platform-specific extensions, you need to note whether there are any differences in how those extensions are implemented on each computer, and use only those features that are identical on both. (For more information, see Portability.) The default is to compile with the full set of extensions available.

Because Visual Fortran compiler directives look like standard Fortran comments (such as !DEC$ directive), programs that use directives can compile on other systems. They will, however, lose their function as compiler directives.

Floating-Point Issues

Floating-point answers can differ from system to system, because different systems have different precisions and treat rounding errors in different ways.

One programming practice that can be a serious source of floating-point instability is performing an IF test (either obvious or implied) that takes some action if and only if a floating-point number exactly equals a particular value. If your program contains code like this, rewrite the code to a version that is stable in the presence of rounding error. For more details, see The Floating-Point Environment.

Another source of floating-point instability is the use of mathematical algorithms that tend to diminish precision. Incorrect answers can result when the code is moved to a system with less precision. For more information, see The Floating-Point Environment.

One way of making all REAL variables on one system DOUBLE PRECISION on another is to use modules to declare explicit data types for each system. Specify a different KIND parameter in each module. Another way is to add an include file that declares explicit data types on each system in all source files.