top_left_banner  SimCon logo

Fortran Migration or Porting

A four year old workstation is obsolete. Scientific and engineering Fortran codes live for decades.
fpt contains powerful tools for migrating code from one computer system to another.

The First Steps in an fpt Migration - Assessing the Task

  1. Copy the Files which Make Up the Program: We recommend working under Linux, OSX or Microsoft Windows. If the original host runs a different operating system, for example, VMS or Gould-SEL MPX, copy the files to the system which you will use for analysis, preserving the directory structure as far as is conveniently possible.
  2. Check for Completeness: The first step is to identify all of the files which make up the program or programs to be migrated. This is most easily done by building an fpt project as described here. The fpt project contains a list of the files and the directories for the primary and include files. If necessary, the project may contain additional commands to interpret the file formats of the original operating system or unusual aspects of the original Fortran syntax. Run fpt and use the command show unresolved references to find out whether anything is missing.
  3. Missing Routines: There may be three classes of missing routines: routines in operating system libraries, routines written in other languages such as C or assembler, and user-written Fortran routines not yet included in the project. If there are missing user-written Fortran routines, repeat the first two steps until all have been found, If there are routines written in other languages, check that everything which they call is available, and add any Fortran routines which they call to the project. Any user-written routines which cannot be found may need to be written as part of the migration task.
  4. Operating System Routines: If the migration is from VMS and the code contains references to the VMS system libraries, we strongly recommend that you contact Sector7 to discuss how the code can be migrated. The VMS system routines have names which begin, for example, LIB$ or SYS$. Sector7 have very complete emulations of the VMS system libraries under Unix and Linux and considerable experience in VMS migration. Sector7 can also advise on PDP11 migrations. If the migration is from Gould-SEL MPX, SimCon have migrated a large proportion of the system routines and can supply codes. Please contact SimCon to discuss other operating system library routines.
  5. Assembler Routines: Any routines written in assembler must be translated. Sector7 have experience in translating VMS and PDP11 assembler, and SimCon have experience in translating Gould-SEL assembler. In these cases the translation is at least partly automatic.
  6. Embedded Assembler: The code to be migrated may contain assembler embedded in-line in the Fortran. This is particularly common in Gould-SEL codes, and in this case SimCon have a partly automated system to translate it to Fortran. fpt issues a warning when embedded assembler is encountered. Search the fpt listing (.fpl) file for the string "assembler".

Preparing Tests

You have assessed the migration task, and now have an fpt project which reads and analyses all of the Fortran files. The next step is to set up acceptance tests so that you can prove that the migration is successful.

  1. Design a Test-suite: Set up one or more program runs to exercise the code on the original host. This test-suite will be run several times. If possible, create a command or batch file to run the tests and capture the output data to file.
  2. Measure the Test Coverage: The coverage analysis measures the proportion of the code which is executed during ther test runs. fpt can systematically modify the code for coverage analysis - see the fpt command insert coverage for a description of this process. Repeat steps 7 and 8 until a satisfactory coverage is achieved.
  3. Set up Record/Replay: The test runs may involve interactive entry of data. Optionally, fpt can instrument the code so that all of the input I/O is captured as it is entered, and can be replayed automatically from a single file. Please see the command insert record/replay. File I/O may also be recorded and replayed, so this command may be used to repeat runs where data are read from a database or file system which might be changed by other processes. Record/replay may also be used to isolate the effects of sub-program calls or inter-process communication. You may choose specific sub-program interfaces to be recorded and replayed.

Checking for Errors

Errors are far less portable than correct code. The effects of a mis-matched argument, for example, will depend on the number format in use. An array reference out-of-bounds will hit different memory locations on different systems.

  1. Make Templates for the Non-Fortran Routines: If the code contains calls to routines written in other languages such as C and assembler, you may, optionally, use the fpt command make templates for missing routines to create templates for them. Check that the templates match the routine interfaces. Where fpt is unable to make a template because the routine has different types of argument in different calls, check that this is consistent with the behaviour of the routine and create an appropriate template by hand. Add the templates to the fpt project.
  2. Check and Correct the Code: Use the interactive commands in fpt to check the code for errors. For example, use the commands check arguments, check names in common and check equivalence. Correct the code. In some cases fpt has commands which make the corrections automatically, e.g. correct inconsistent arguments. In other cases the corrections must be made by hand. Re-test the corrected code on the original host. If the code doesn't run correctly on the new host, we need to know that this is because of the migration process, not because of an existing bug which has shown its symptoms in a new way. See the Quality Assurance pages for further description of the checks.

Converting the Code

  1. Make an fpt Project to Convert the Code: fpt converts many language extensions to standard code in a single pass and in very much less time than the Fortran compilation. Make an fpt project to produce the changes required, and run it repeatedly, making test compilations on the new host, until everything builds. In this way we avoid the situation where the source is modified manually through intermediate stages where it won't run on either host. The changes required depend on the characteristics of the hosts. fpt has extensive facilities for migration:

Testing and Debugging the Migration

  1. Run the Test-suite on the New Host: Run the test-suite on the new host and attempt to replicate the results from the original host. Iterate steps 14 and 15 until a reasonable match is achieved.
  2. Finding Why the Results are Different: It is very unlikely that the results of a large program will be exactly the same on two different hosts. Small differences in rounding, due to different orders of computation within expressions cause numerical drift between the results. fpt may be used to eliminate numerical drift, using the run-time trace facility. This may expose errors in the original code or in the compilers.

Copyright ©1995 to 2017 Software Validation Ltd. All rights reserved.