TR-2004-012

The Transformation of Legacy Software:

Some Tools and a Process (Version 3)

Dr C Greenough and Dr DJ Worth

March 2006

Abstract

This report provides some insight into the software tools currently available to assistin transforming legacy Fortran programs to the new 1990 and 1995 standards.

Given that the scientific community has a vast number of man years invested inFortran based application programs it is very surprising that there is very littlepublished work dealing with this problem. The only notable exception is in the workof Decyk and Norton from NASA’s Jet Propulsion Laboratory [2, 3, 4] who haveproposed a staged process for moving old Fortran to Fortran 90/95.

There are some publications from the commercial world recognising the difficultieswith large COBOL or Web systems. One example is from Tata Infotech, an Indiantechnology company based in Mumbai [6].

Another way forward is to consider translation into a completely different languagesuch as C or C++. There is brief comment on this approach and some availabletools.

This report is particularly concerned with tools which will enhance the quality ofsoftware developed. We have not looked at tools which focus on the high leveldesign and requirements analysis, since these are often common to many languages.Instead we have concentrated on tools that help in the transformation process andthe detection of programming errors and highlight poor practice, such as spaghetti

style coding.

Keywords: legacy software, transformation, software quality, Fortran 90/95

Email: c.greenough@rl.ac.uk

Reports can be obtained from www.softeng.cse.clrc.ac.uk

Software Engineering GroupComputational Science & Engineering DepartmentRutherford Appleton LaboratoryChilton, DidcotOxfordshire OX11 0QX

c© Council for the Central Laboratory of the Research Councils

Enquires about the copyright, reproduction and requests for additional copies of this reportshould be address to:

Library and Information ServicesCLRC Rutherford Appleton LaboratoryChilton, DidcotOxfordshire OX11 0QX

Tel: +44 (0)1235 445384Fax: +44 (0)1235 446403Email:library@rl.ac.uk

CLRC reports are available online at:

http://www.clrc.ac.uk/Activity/ACTIVITY=Publications;SECTION=225;

ISSN 1358-6254

Neither the Council nor the Laboratory accept any responsibility for loss or damage arising fromthe use of information contained in any of their reports or in any communication about theirtests or investigations

Contents

1 Introduction 1

2 What is Legacy Software 1

3 A pragmatic process for legacy software 2

4 Software engineering tools 3

5 Author recognition 4

6 The transformation process and associated tools 46.1 Conditional compilation and preprocessors such as cpp . . . . . . . . . . . . . . . 4

6.1.1 The basic problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46.1.2 Some more interesting problems . . . . . . . . . . . . . . . . . . . . . . . 56.1.3 What can be done? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

6.2 Fortran COMMON blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76.3 Source INCLUDE statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86.4 Subprogram INTERFACE Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.5 IMPLICIT variable typing and REAL*8 statements . . . . . . . . . . . . . . . . . . 116.6 Statement functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7 Use of more modern languages 14

8 Software re-engineering and modularisation 15

9 Componentisation and encapsulation 16

10 Vectorisation and parallelisation tools 20

11 Memory leakage detection 21

12 Maintaining quality 22

13 Conclusions 23

A Some transformation tools 26A.1 Numerical Algorithms Group Ltd. - NAGware tools . . . . . . . . . . . . . . . . . 26A.2 Polyhedron Software Ltd - plusFort tools . . . . . . . . . . . . . . . . . . . . . . 27A.3 Leiden University FORCHECK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28A.4 Understand for Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28A.5 Simulog FORESYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.6 QA Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.7 McCabe IQ Toolset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.8 VAST/77to90 from Crescent Bay Software [20] . . . . . . . . . . . . . . . . . . . 29

B Language translation 31B.1 PROMULA Fortran to C translator/compiler - http://www.promula.com . . . . 31B.2 f2c - Fortran 77 to C translation [1] . . . . . . . . . . . . . . . . . . . . . . . . . 33B.3 The f2j project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

C Vectorisation and parallelisation tools 35C.1 Crescent Bay Software - VAST/77to90 . . . . . . . . . . . . . . . . . . . . . . . . 35C.2 Parallel Software Products Inc. - ParaWise . . . . . . . . . . . . . . . . . . . . . 35

i

C.3 PIPS and WPIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

D The Polyhedron Software Ltd. mkkind Program 38

ii

1 Introduction

In many projects in computational science it has been long recognised that more formal or moremodern processes of software development are required. Computational science is clearly notalone in facing this type of problem. Any organisation that has a large investment in computersoftware, be it written in Fortran or COBOL or any developing language, will face similardecisions. This report looks primarily at Fortran based software and presents a pragmaticprocess for moving software development forward. The steps in the process are really selfevident but we attempt to relate these steps to the availability of software tools that might aidthe transition.

Software engineering advances, such as component-based design and object-oriented program-ming can improve the usability and management of research applications. However these willtend to address new designs and new software. The problem of old - legacy - software remains.

In this report we consider an approach that could be taken to retain the functionality oflegacy software whilst moving its maintenance and future development processes forward. Wedraw heavily on the work of Norton and Decyk [2, 3] at the Jet Propulsion Laboratory who havemade great strides in developing a systematic approach for the rescue of intellectual propertyembedded in legacy systems.

2 What is Legacy Software

We should ask the question: What is Legacy Software?We can in part answer this question following Bashir [8] modifying his words to capture

the requirements of our scientific domain. However it should be said that there is really verylittle difference between the commercial world and the scientific community when it comes tocomputer software. Legacy software can be characterised informally as old software that is stillperforming a useful job for the community. Legacy software systems are programs that are stillwell used by the community or have some potential inherent value but that were developed yearsago using early versions of Fortran or other languages.

Often these programs have been maintained and developed for many years by hundredsof programmers, and while many changes have been made to the software, the supportingdocumentation may not be current and the programming style from the dark ages. Thesefactors contribute to the staggering cost of maintaining these legacy programs or continuingtheir development.

Consequently, there is an urgent need to find ways to make these programs more maintainablewithout disrupting their current use and to safeguard the information they contain.

The implication is that the preferred solution is to discard the software completely, and startagain with a new system. This may not be appropriate in all cases, for example after [8]:

• The software represents years of accumulated experience, which is not represented else-where, so discarding the software will also discard this knowledge, however inconvenientlyit is represented.

• The software may actually work well, and its behavior may be well understood. A newreplacement system may perform much worse, at least in the early days. Hence it may beworth recovering some of the good features of the legacy system.

• A typical large legacy software system has many users, who typically have exploited un-documented features and side effects in the software. It may not be acceptable to demandthat users undertake a substantial rewrite for no discernible benefit. Therefore, it may beimportant to retain the interfaces and exact functionality of the legacy code, both explicitand implicit.

1

• Users may prefer an evolutionary rather than a revolutionary approach to modernisingtheir software

Norton and Decyk have taken on board many of these ideas in their approach to modernisingFortran systems. However they identify two additional characteristics of computational softwarewhich are important to the scientific community: firstly that the software is generally welldebugged and secondly the software produces results that are trusted. Generating new softwarewill most often introduce new bugs and this would certainly degrade the users trust in theprogram’s results.

3 A pragmatic process for legacy software

For many applications within the science and engineering community the root implementationlanguage was and still is Fortran 77 and for some, even Fortran 66. Software engineering hasdeveloped and languages have grown and now Fortran 95 (soon to be Fortran 2003), C and C++provide the main modern vehicles for these applications. However we will make the assumptionthat the majority of the software of interest is in Fortran (of some form) and that the targetlanguage is Fortran 90/95. However the process could just as easily be applied to all software -even new implementations as they are often as non-standard as their historic counterparts.

To maintain and continue to develop the science encapsulated in these codes a process oftransformation and re-engineering must be formalised and undertaken. This process can bebroken into three basic steps:

• standardisation,

• transformation and

• re-engineering.

The re-engineering step in [4] is broken down into four steps as shown in six stage process ofFigure 1.

Components & OO

IntegrationAbstraction

CompilationStandard−Base

standard complinaceTransform software into

Legacy Software

Interfaces for all routines

Create Interfaces

Wrappers for legcay code

Undesirable Features

COMMON BlocksImplicit typing

#def/#if statementsInclude statement

InterpoerabilityArray Operations

Add New Capabilities

Dynamic memory

Figure 1: Step-by-Step Process for Legacy Software [4]

Standardisation: Get the base code into a conforming form. As mention above often legacycodes are in Fortran 77 or 66 or even worse a mixture of standards and dialects. In general

2

the standard of research programming is limited and most often leads to not particularlyportable software. The developers often adopt mechanisms from other languages: themain example of this is the # directives from the Unix C pre-processor cpp. #include,#define and #ifdef are the three main culprits. It is fortunate that most other directiveswhich are added to Fortran programs are expressed as comment lines e.g HPF.

Transformation: Move to something new. Once the basic code is in a standard form automatedtransformation tools can be used to change the software format (e.g. fixed-form Fortran77 to free-form Fortran 95). This can be purely a source to source transformation and nostructural changes are made. These types of transformation are often thought of as prettyprinting. However some transformation tools will perform limited re-structuring of theprogram as it is being transformed: the replacement of computed GOTO statements withIF-THEN-ELSE blocks, moving of statements to aid efficiency and the inclusion of MODULEand USE statements.

Re-Engineering: Two modes of re-engineering can usefully be identified: code preservation andcode modernisation. In some cases it may be thought necessary that the original legacycode be maintained as is for some compatibility reasons. If this is the case then code canbe wrapped in some appropriate statements that will enable the legacy code to be calleddirectly. This is code preservation.

On the opposite front there are many new features in Fortran 90/95 that will improve thequality of an application in performance, maintenance and development potential. Examples are:modules, derived data types, dynamic memory management, pointers and allocatable arrays.The use of these is the process of modernisation.

This is the most difficult part of the transformation process as it may require considerablere-writing of the software. The first stage of this re-engineering is to rid the software of theundesirable features of earlier versions of Fortran: COMMON blocks, IMPLICIT typing of variablesand the use of INCLUDE and BLOCKDATA statements are examples.

Once this basic first stage of the re-engineering process is complete more complex re-engineeringcan be considered. As mentioned above the use of Fortran 90/95 features such as dynamic mem-ory or user defined data.

During this stage the encapsulation of the legacy code in suitable wrappers can also beconsidered. Although transformed into the new source form it may be considered appropriateto isolate use of dynamic memory allocation from the basic code. From here we can move onto look at the use of object orientation techniques which can, in the long term, improve themaintenance and future development of the program.

We will consider in the following sections each of these steps outlined above and relate tothat part of the process some tools that may assist the process.

4 Software engineering tools

Throughout the following sections reference will be made a to a few of the software engineeringtools that can assist programmers in updating and improving their software. A short descriptionof these and few other tools are given in Appendix A and a fuller survey of software engineeringtools for scientific applications is given in [37, 38].

There is a good selection of tools to help the programmer in transforming and improve theirsoftware. The first step is often the hardest: is my program really Fortran 77 or Fortran 90/95?- the problem of conformance to a single language standard. It is often the case, in academicresearch projects, that the software developed is a arbitrary mixture of various Fortran standards,styles and extensions.

Some of these tools provide a Fortran 77 to Fortran 90/95 translation (only really a formatchange) and others provide additional functionality to convert COMMON blocks and INCLUDE files

3

into MODULES together with utilities to generate INTERFACE blocks. Although some of themattempt a restructuring of the software to remove some of the undesirable features of Fortran 77none will generate memory allocation directives or identify places where the Fortran 90/95 arraysyntax can be used.

Two groups of tools have been heavily used to good effect in the current moderisation work:the NAGWare tools from the Numerical Algorithms Group Ltd. [34, 35] and the plusFORT toolsfrom Polyhedron Software [36].

5 Author recognition

An interesting byproduct of the transformation process is the problem of author recognition -not surprisingly developers and authors have a mental image of their software. They are oftenable to recognise where they are in a code by its appearance and the structure of the code onthe screen - they have a set of visual bookmarks. These help greatly in the development of thesoftware. However after transformation the originator or current developer of the code findsthat they no longer recognise the software: the structure and the formating of the statementson the page may well have changed. For the developers this may reduce their productivity indevelopment and hence they will be reluctant to use the newer version as the basis of futuredevelopment. Although Fortran 77 is subset of Fortran 95 - apart from a few redundant anddeprecated features - it would be against the spirit of the process to just continue to programin compliant Fortran 77.

Fortunately it is possible to set the control parameters of most re-formating and transforma-tion tools to produce output that is not too dissimilar to that of the original - even when movingfrom Fortran 77 to Fortran 95. For example, although Fortran 95 has a basically free formatform, programs such as plusFORT can output statements with suitable indentations. Simplechanges such as having all the Fortran keywords in upper or lower case can markedly change theauthors view of their software. Author have their likes and dislikes so it is important to matchthese, if possible, with the effects of the transformations applied.

6 The transformation process and associated tools

In this section we look at some of the steps in the standardisation and transformation processoutlined in Section 3 and discuss some of the difficulties that might be encountered and some ofthe tools that might help automate the tasks.

The starting point of this process must be a body of standardised code, documentation, testdata and their resultant outputs. This material will be used to inform, control and providecheckpoints within the process as well as ensure that the author(s) and users of the softwarewill have confidence in the software in its new form. Involvement of the authors is essential, asthey need to develop a new image of their software.

6.1 Conditional compilation and preprocessors such as cpp

6.1.1 The basic problem

Conditional compilation is a very useful feature for developers who need to install their softwareon multiple platforms. The use of a pre-processor as a configuration tool allows the maintenanceof multiple configurations in a single file. However as far as software engineering tools areconcerned statements such as #define and #if, that drive preprocessors such as cpp and fpp, arenot part of the Fortran language and lead to syntax errors being flagged. Even the preprocessorcoco [10], now being developed as a component of the Fortran 2003 standard, has the samedifficulty. Preprocessors provide the programmer with an excellent configuration tool but theyare a nightmare to any syntax checking or standard conformance tool.

4

For example most of the NAGWare tools will in general generate some form of syntax errorwhen processing source files that contain cpp directives. However the spag tool from plusFORT insome sense recognises the cpp directives and comments them out. This can have some interestingconsequences when the directives enclose declarations or initialisation statements..

Pre-processor directives add another layer of complexity to analysis and transformation tools.Neither the NagWare tools and the plusFORT tools take kindly to cpp directives.

6.1.2 Some more interesting problems

Use of cpp can lead to unexpected, even mistaken, results due to Fortran’s source file format.Macro expansions, if used, must be used with great care as the macro name can very easily arisein the Fortran source in unexpected places. It is recommended that use of the C preprocessorbe limited to #include and, in conjunction with #define, only #if and related directives, thusavoiding in-line macro expansion entirely. This recommendation applies especially when usingthe traditional fixed source form.

With free source form, fewer unexpected transformations are likely to happen, but use ofconstructs such as Hollerith and character constants can nevertheless present problems, espe-cially when these are continued across multiple source lines. These problems result, primarily,from differences between the way such constants are interpreted by the C preprocessor and by aFortran compiler.

Another example of a problem that results from using the C pre-processor is that a Fortrancomment line that happens to contain any characters interesting to the C pre-processor, suchas a backslash at the end of the line, is not recognized by the pre-processor as a commentline, so instead of being passed through raw, the line is edited according to the rules for thepreprocessor. For example, the backslash at the end of the line is removed, along with thesubsequent newline, resulting in the next line being effectively commented out - unfortunate ifthat line is a non-comment line of important code!

Some version of cpp will fail when they encounter a Fortran comment line that contains anapostrophe. Because Fortran and C differ in their treatment of some sequences of characters,care is required when using /* or */ (which might be interpreted as C comment delimiters,possibly causing problems even if they occur inside Fortran comments), and also when usingthree-character sequences beginning with“??” (which might be interpreted as C trigraphs).ISO standard trigraph sequences are three-character sequences, all starting with “??”, that aredefined by ISO C to stand for single characters. For example, “??/” stands for “\” and “??/n” isa character constant for a newline. By default most compilers ignore trigraphs, but in standard-conforming modes they are converted into the appropriate characters. Consider the followingexample:

program test case

character a

character*4 word

a = ’?’

word(1:2) = ’??’

print *, word(1:2)

end program testcase

If the pre-processor matches your character combination with the corresponding trigraph se-quence, your output may not be what you expected. “??`” could well be the trigraph for the“^” character.

When using cpp on Linux systems the -traditional option can help avoid some of theseproblems most of which arise from ISO C. Using the -traditional will ensure that single-quotesand double-quotes within Fortran comment lines (which are generally not recognized as such bythe preprocessor) do not cause diagnostics about unterminated character or string constants.

However, this option will not prevent diagnostics about unterminated comments when a C-style comment appears to start, but not end, within Fortran-style commentary. So, the following

5

Fortran comment lines are accepted with -traditional:

C This isn’ t an unterminated character constant

C Neither is "20000000000, an octal constant

C in some dialects of Fortran

However, this type of comment line is likely to produce a diagnostic, or at least unexpectedoutput from the preprocessor, due to the unterminated comment:

C Some Fortran compilers accept /* as starting

C an inline comment.

The difficulties with cpp have been recognised by the Fotran community and Fortran aware pre-processors have been development. coco and fpp are two such Fortran aware pre-processors.In general these pre-processors generally do not have the problem with ISO trigraphs and C

comment delimiters.An additional problem are the line markers generated by cpp. For example:

#I "main.f.in"

gets added to main.f when main.f.in is processed by cpp in some compilation systems. Thesecan be suppressed by using the -P flag on most cpp implementations.

6.1.3 What can be done?

For transformation and anlysis tools to work correctly cpp pre-processor commands must beremoved. Basically either the source is pre-processed for one specific configuration, processedand the cpp directives re-introduced as a post-processing step or the effects of the directivesmust be neutralised before re-engineering but the information they contain preserved in someway.

Pre-processing with cpp and a suitable sets of -Ds will lead to multiple source - as is generallythe intention. If the processing is only a standard conformance check or portability check thenprocessing multiple sources is not a problem. However if the processing is a transformation ofthe source merging the transformed sources and re-introducing the cpp directives is a seriousproblem.

Some simple awk filters have been developed to aid in the assessment of cpp directives andtheir effect on the transformation tools: ccp-analyse, cpp-remove and cpp-restore. Theseonly perform some simple single-pass processing so they are currently very limited in their scope.A better solution would be to build this type of analysis into the transformation tools.

cpp-analyse : this script scans the Fortran file and detects cpp directives. These are output asdiagnostics and places where possible conflict could arise are flagged. These areas are thosein which there are variable type specifications, INCLUDE statements and USE statementsa within cpp directive block. In general executable statements within a cpp directiveblock will not present a problem provided the tool processing the software does not movecomment statements.

cpp-remove : this script will remove (comment out) cpp directives and non-executable state-ments that cause specification conflicts.

cpp-restore : this script will restore cpp directives within the source on the assumption thatthe relative position of the comment statement has not moved. This is true in mostsituations in the body of a source file but may not be true at the file’s head.

A major deficiency with this process is the some source lines may contain the only reference to aparticular variable or structure within the module. Many tools will remove references to unusedvariables and structures which will lead to compiler errors once the ccp directives have beenrestored and used to generate subsequent versions. Fortunately some tools provide an optionfor not performing this removal of unused variables.

6

6.2 Fortran COMMON blocks

Probably one of the most undesirable and most useful of the pre-Fortran 90/95 features is theCOMMON block. As the only mechanism for providing global data it has been heavily use inmost Fortran programs. Their use is run a close second by their mis-use. Named and un-named COMMONs have been the hiding place of pseudo-dynamic memory management, implicitequivalencing of variables of differing types and various other Fortran tricks. Even those whoused them sensibly are driven to using INCLUDE statements (or worse #include) to help ensurethat COMMON definitions were consistent throughout the program. We will comment on theINCLUDE, EQUIVALANCE and IMPLICIT type statements in the following section.

Fortran 90/95 provides a versatile and safe mechanism for making global information availableto program units through the MODULE. The USE statement removes the need for the INCLUDE

statement to make the globals available consistently throughout the program.The construction of an equivalent MODULE block for a COMMON block is quite straightforward.

However if the program contains a large number of COMMONs this could be a daunting task.Fortunately many software tool suites provide this conversion process: using the NAGWare toolnag cmb95 and in the configuration files for spag, setting the value of switch number 4 to 40,will provide the conversion of all COMMON blocks to MODULES (and in the case of spag also allINCLUDE files).

The effects of these tools is best demonstrated by a simple example. Below is shown a simpleFortran 77 program that includes a COMMON block.

C

PROGRAM SIMPLE

C

C*** Start of declarations

C

C COMMON variables

C

REAL ARG1(10,10), ARG2(10,10)

LOGICAL ARG3

INTEGER ARG4

COMMON /ARGMNT/ ARGl, ARG2, ARG3, ARG4

C

C Local variables

C

INTEGER I, J, U2

REAL Ul

SAVE /ARGMNT/

EXTERNAL SUBl

C

C*** End of declarations

C

U2 = 5

DO 100 I = 1, 10

DO 50 J = 1, 10

ARG1(I,J) = I*J

50 CONTINUE

100 CONTINUE

C

PRINT * ,"Program Started"

C

CALL SUB1(Ul,U2)

C

PRINT * ,"Program Ended"

C

END

7

when this processed by the NAGWare tool nag cmb95 produces (with a few minor edits):

PROGRAM simple

USE argmnt, ONLY: arg1, arg2, arg3, arg4

! Local variables

INTEGER :: i, j, u2

REAL :: u1

EXTERNAL sub1

u2 = 5

DO i = 1, 10

DO j = 1, 10

arg1(i,j) = i*j

END DO

END DO

PRINT *, ’Program Started’

CALL sub1(u1,u2)

PRINT *, ’Program Ended’

END PROGRAM simple

which is a Fortran 90/95 version with the COMMON block extracted into a module and its referencereplaced by a USE statement. The COMMON block module is show below.

MODULE argmnt

REAL: : arg1(10,10), arg2(10,10)

LOGICAL: : arg3

INTEGER: : arg4

SAVE arg1, arg2, arg3, arg4

END MODULE argmnt

This module can be collected together with other COMMON block modules, compiled and USEdas necessary. Any changes to this module will be available in all subprograms that reference itafter re-compilation. Clearly this overcomes one of the major sources of error and unexpectedresults in providing global data within Fortran programs.

6.3 Source INCLUDE statements

It is sometimes useful to be able to reuse common source lines. Although in Fortran 77 manycompilation systems provided this facility through the INCLUDE statement as an extension tolanguage many programmers resort to using the cpp directive #include. The usefulness ofthis facility has been recognised in the Fortran 90/95 standard with a formal definition of theINCLUDE statement. This definitions lead to a pre-processing step by the compiler which inlinesthe required language statements. INCLUDE files may contain INCLUDEs provided they are notrecursive.

More often than not INCLUDE files contained references to the specification of global variablesand COMMON definitions. INCLUDE files have rarely been used to duplicate executable statements.However they can be used for this purpose and may appear anywhere within the programunit. Unfortunately some tolls make the incorrect assumption that INCLUDE file only containspecification statements so care is required.

In Fortran 90/95 the same functionality is better achieved by placing any global definitionsin a module and making reference to these definitions through a USE statement.

8

Some software tools extract and transform such included statements into modules. spag

from the plusFORT tools set does this. Any include statements in the source are removed andreplaced by suitable USE statements. Below is shown a simple example (example.f) of the useof an INCLUDE example.inc and the effect of processing with spag.

subroutine sub1

include ’example.inc’

angle=2.0*pi/4.0

c ....

c Body of subroutine

c ...

end

C*********************************************************************

C

C Include (example.inc) file containing system parameters

C

C*********************************************************************

real*8 pi,sqrpi,boltz

integer kmaxa,kmaxb,kmaxc,minnode,msbad,mxfix

common/params/kmaxa,kmaxb,kmaxc,minnode,msbad,mxfix,

parameter (pi =3.141592653589793d0,sqrpi =1.7724538509055159d0)

parameter (boltz =8.31451115d-1)

Processing with spag generates a new module, I example.f90, from the include file which isUSEd in the transformed calling code.

MODULE I_example

USE F77KINDS

IMPLICIT NONE

!

! PARAMETER definitions

!

REAL(R8KIND) , PARAMETER :: PI = 3.141592653589793D0 , &

& SQRPI = 1.7724538509055159D0 , &

& BOLTZ = 8.31451115D-1

!

! COMMON /PARAMS/

!

INTEGER :: KMAXA , KMAXB , KMAXC , MINNODE , MSBAD , MXFIX

END MODULE I_example

SUBROUTINE SUB1

USE I_example

IMPLICIT NONE

REAL :: angle

angle = 2.D0*PI/4.D0

! ....

! Body of subrotuine

! ...

9

!

END SUBROUTINE SUB1

6.4 Subprogram INTERFACE Blocks

In many Fortran compilers there have been additional debugging options provided to comparethe types and sizes of subprogram dummy arguments against the actual arguments. These haveprovided a very important debugging tool as the correspondence of dummy to actual argumentsin a subprogram call harbors many runtime errors - pass an integer into a real and strangething can subsequently happen. Fortran 90/95 provides a mechanism which can eliminate thesetypes of run-time problems by providing the compiler with sufficient information the check tocorrespondence between actual and dummy arguments.

In the simplest case where all the code for a program and its subprograms are held in asingle file the Fortran 90/95 compiler can assemble all the information it requires to check thecorrespondence between actual and dummy arguments. The subprogram interfaces are said tobe explicit. In general most interfaces in well designed Fortran 90/95 software will be explicit.The compilation system will organise the information to perform actual and dummy argumentchecking. Any subprogram defined within a CONTAINS statement (an internal subprogram) orwithin a MODULE block will provide explicit interface information.

The only problem occurs when a subprogram is defined outside the scope of the current pro-gram - most commonly in an external library. During compilation the compiler has no automaticinformation about the subprogram’s interface. In using such external libraries the programmercan do one of two things for the compiler. Either declare the subprograms as EXTERNAL orprovide an INTERFACE block. The interface to these external subprograms can be provided tothe Fortran 90/95 compilation systems through the INTERFACE block. Naming a subprogram asEXTERNAL reserves the name and makes any intrinsic of the same name unavailable. Essentiallythe subprogram name has a specific type. By providing an interface block the programmer de-scribes the subprogram’s argument list to the compiler. This re-instates the potential for actualand dummy argument checking.

Tools such as the plusFORT spag and the NAGWare nag mkintf95 can generate interfaceblocks. These are particularly useful if the software being developed is a library which usersare going to call from within their programs. These users can USE these definitions, if they aregathered into a module, within their programs to define the interfaces. The interface block bodyis really an copy of the subprogram’s header, the specification of its arguments, return valuetypes if a function and its end statement.

An example of the output of the NAGWare nag mkintf95 tool is given below. Firstly the headand tail of the subprogram:

FUNCTION lafind(it,nnn,lsi,lsa)

!*********************************************************************

! dl_poly function to find the local atom number given the

! global atom number (for use with domain decomposition code)

! author - w.smith jan 1999

! copyright daresbury laboratory jan 1999

!*********************************************************************

IMPLICIT NONE

! Dummy arguments

INTEGER :: it, nnn

10

INTEGER :: lafind

INTEGER, DIMENSION (nnn) :: lsa, lsi

INTENT (IN) :: it, lsa, lsi, nnn

! Local variables

INTEGER :: i, i1, iz, k

!*** End of declarations rewritten by SPAG

.................................

END FUNCTION lafind

and secondly the interface block generated by nag mkintf95.

MODULE nag_mkintf95_mod

INTERFACE

FUNCTION lafind(it,nnn,lsi,lsa)

INTEGER :: lafind

INTEGER, INTENT (IN) :: it

INTEGER, INTENT (IN) :: nnn

INTEGER, INTENT (IN) :: lsi(nnn)

INTEGER, INTENT (IN) :: lsa(nnn)

END FUNCTION lafind

END INTERFACE

END MODULE nag_mkintf95_mod

6.5 IMPLICIT variable typing and REAL*8 statements

At the time the IMPLICIT statement and the implicit variable type conventions must have seemeda good thing. With hindsight, it is clear, they were not. All the evidence in software maintenanceand re-engineering points to the fact that IMPLICIT type statements and the implicit typingconventions obscure and confuse. Although the IMPLICIT type statement is still part of theFortran 90/95 standard it is clear that the only IMPLICIT statement that really should appearin all code is:

IMPLICIT NONE

This not only enforces no implicit typing but is stronger. It ensures that all variables must beexplicitly typed and consequently correctly used in assignments and, by the use of explicit andimplicit interface information, procedure calls.

In the similar vein the use of REAL*8, INTEGER*2 and LOGICAL*1 are all extensions to For-tran 77 and were not part of the formal standard. These should be replaced with suitableFortran 90/95 equivalents: REAL (KIND=DP), INTEGER (KIND=1)or LOGICAL(KIND=1). How-ever it should be noted that the KIND definitions are dependent on the compilation system -they are not defined in the standard. Two examples are shown in Table 1. These modules weregenerated automatically using MKKIND.F90 program that is supplied with the plusFORT toolkitfrom Polyhedron Software (see Appendix D). They map common non-standard Fortran 77 typesto Fortran 90/95 kinds because different Fortran 90/95 compilers use different kind vaules. Ascan be seen in the table above. For example: R8KIND=2 (REAL*8) for the NagWare f95 compilerand for the Intel ifc compiler R8KIND=8 (REAL*8).

It is a common mistake to assume that:

REAL*8 ⇒ REAL(8)

orDOUBLE PRECISION ⇒ REAL(8)

11

MODULE F77KINDS MODULE F77KINDS

! !

! F77KINDS for NagWare f95 compiler ! F77KINDS for Intel ifc compiler

! !

INTEGER,PARAMETER :: & INTEGER,PARAMETER :: &

I1KIND = 1, & ! INTEGER*1 I1KIND = 1, & ! INTEGER*1

I2KIND = 2, & ! INTEGER*2 I2KIND = 2, & ! INTEGER*2

I4KIND = 3, & ! INTEGER*4 I4KIND = 4, & ! INTEGER*4

L1KIND = 1, & ! LOGICAL*1 L1KIND = 1, & ! LOGICAL*1

L4KIND = 3, & ! LOGICAL*4 L4KIND = 4, & ! LOGICAL*4

R4KIND = 1, & ! REAL*4 R4KIND = 4, & ! REAL*4

R8KIND = 2, & ! REAL*8 R8KIND = 8, & ! REAL*8

DPKIND = 2, & ! DOUBLE PRECISION DPKIND = 8, & ! DOUBLE PRECISION

CX8KIND = 1, & ! COMPLEX*8 CX8KIND = 4, & ! COMPLEX*8

CX16KIND= 2 ! COMPLEX*16 CX16KIND= 8 ! COMPLEX*16

END MODULE F77KINDS END MODULE F77KINDS

Table 1: Mapping common non-standard Fortran 77 types to Fortran 90/95 kinds

REAL(8) specifies a real variable with KIND=8. This may or may not be a DOUBLE PRECISION

real depending on the compilation system. A straightforward way of ensuring the correct valueof KIND is used is to define a DPKIND using:

INTEGER, PARAMETER :: DPKIND = KIND(1.0D0)

and to use this in all subsequent specifications of DOUBLE PRECISION variables. It is possibleto be more specific in defining the precision and exponent range of the required real definitionusing the SELECTED REAL KIND intrinsic but this will only be able to map the requirement ontothe available KIND values. It is a good idea for a programmer engaged in software re-engineeringto check on the KIND values used by their compilers.

6.6 Statement functions

The statement function is a well used element of the Fortran 77 language as it provides a compactway of defining small functions to be used within the context of a program unit. The statementfunction is flagged as an obsolescent feature in the Fortran 90/95 standard and may well beremoved in future revisions of the language.

Its equivalent in Fortran 90/95 is an internal program. Although these are not as compactas statement functions they have the same functionality and better control over their definition.Internal subprograms may appear in any of the major Fortran 90/95 program units: main pro-grams, modules and external subprograms. They have the same structure as all other programunits but they are placed after the CONTAINS statement in the unit. The CONTAINS statementflags the presence of one or more internal subprograms.

Below is shown a typical section of code in which statement functions are defined. Notethat statement functions are legal Fortran 90/95 statements at present. Many Fortran 90/95compilers will give a warning when encountering a statement function remarking that they areobsolescent.

PROGRAM moldyn

IMPLICIT NONE

!

! PARAMETER definitions

!

INTEGER , PARAMETER :: R8KIND = 8

REAL(R8KIND) , PARAMETER :: PI = 3.141592653589793D0

!

! Local variables

!

12

REAL(R8KIND) :: a , b , c , d , t , x , y

REAL(R8KIND) :: gt6 , sw1

!

! Statement Functions

!

sw1(x,y,a) = exp(-(x**8+y**8)/a**8)

gt6(t,x,y,a,b,c,d) = a*(t**(c-1.D0)*(t-b)*(t+b-2.D0*PI)*((c+4.D0)*&

& t**2-2.D0*PI*(c+2.D0)*t+c*b*(2.D0*PI-b)) &

& -c*PI**(c-1.D0)*(t-b)*(PI-b)**3)*sw1(x,y,d)

!

!.................

! Rest of calling program

!.................

!

!

END PROGRAM moldyn

Currently the available tools do not provide the automatic removal and re-construction of state-ment functions. However as they are generally only small elements of code this transformationcan be performed by hand. A result of this process is shown in the source code below.

PROGRAM moldyn

IMPLICIT NONE

!

! PARAMETER definitions

!

INTEGER , PARAMETER :: R8KIND = 8

REAL(R8KIND) , PARAMETER :: PI = 3.141592653589793D0

!

!.................

! Rest of calling program

!.................

!

CONTAINS

!

! Function SW1

!

FUNCTION sw1(x,y,a)

IMPLICIT NONE

!

! Dummy arguments

!

REAL(R8KIND) :: a , x , y

REAL(R8KIND) :: sw1

INTENT (IN) a , x , y

!

sw1 = exp(-(x**8+y**8)/a**8)

!

END FUNCTION sw1

!

! Function GT6 - Statement Function

!

FUNCTION gt6(t,x,y,a,b,c,d)

IMPLICIT NONE

!

! Dummy arguments

!

REAL(R8KIND) :: a , b , c , d , t , x , y

REAL(R8KIND) :: gt6

13

INTENT (IN) a , b , c , t

!

gt6 = a*(t**(c-1.D0)*(t-b)*(t+b-2.D0*PI) &

& *((c+4.D0)*t**2-2.D0*PI*(c+2.D0)*t+c*b*(2.D0*PI-b)) &

& -c*PI**(c-1.D0)*(t-b)*(PI-b)**3)*sw1(x,y,d)

!

END FUNCTION gt6

END PROGRAM moldyn

Internal subprograms may not be nested, that is they may not contain further subprograms.The use of these re-defined statement functions by the compiler will be identical to all other sub-programs. Again, depending on the original compilation system, there may well be performanceimplications in re-engineering statement functions. For example there may be an overhead incalling a function that was previously inlined?

7 Use of more modern languages

There is a growth in the use of other languages and programming models other than the proce-dural style of Fortran. Languages such as C++ and the use Object Orientation are becomingmore common in numerical software.

There is a need within the UK community to assess the potential of these languages andprogramming paradigms in the context of computational science. There appears to be someresistance to moving to languages such as C++ in many research projects. This is often dueto the heavy investment in Fortran-based software over many years. However the dominanceof Fortran in many computational science and engineering projects does not rule out the use ofthe most up to date software engineering techniques such as object orientation (OO).

Fortran 95 and Fortran 2003 will provide the programmer with many of the modern program-ming constructs and mechanisms without abandoning the basic formula translation paradigmof Fortran.

It would be clearly an advantage for many if there were tools to perform the direct translationsof one programming language into another: Fortran 77 to C++ for example. Clearly this iscurrently an impossible task. Translating the statements of a simple procedural language intoone that it is rich in object orientation, user definable operators and user definable data typesis a tall order.

There are a few tools that provide a simple translation of Fortran into very basic C. As onemight expect none of the more interesting features of the language are utilised. These are veryworkman-like translations of the source form. Two such tools are the PROMULA Fortran to C

translator [18] and the public domain tool f2c [19].The PROMULA tools translates Fortran source code into reasonable and clean C source

code. It is intended for those who wish to convert their Fortran codes to C automatically; 100percent conversion rates are achieved routinely. The conversions yield reproducible results andare repeatable and verifiable. A number of input Fortran dialects are supported via a dialectdefinition flag, and the form of the output C code is controlled by a multitude of command-line switches. The translations may be used in conjunction with a standard C Compiler as ageneral-purpose, multi-dialect and portable Fortran compiler.

A second such tool is f2c. Originally developed at ATT Bell Laboratories starting in the1980s this tool has been much used by the Fortran community. As shown in Appendix Balthough this a good tool its output is rather difficult read.

f2c can be used by sending to netlib@netlib.bell-labs.com a message whose first line isexecute f2c and whose remaining lines are the Fortran 77 source that you wish to have converted.Return mail brings you the resulting C, with f2c’s error messages between #ifdef uNdEfInEd

and #endif at the end. You can put execute f2c in the subject line of the Email instead of (butnot as well as) in the first line of the message body. The incoming Fortran is saved, at least for

14

a while.More details on these two tools, together with some samples of their outputs, can be found

in Appendix BThe Java programming language [14] has grown dramatically in popularity in recent years

in both industry and academia. It has currently found its role in Web programming and GUIsbut now some interest is being shown in the language for high-performance and scientific ap-plications. One very serious attempt to exploit Java in a computational context has been thef2j project. The primary motivation of the f2j project is to provide numerical linear algebrasoftware originally written in Fortran as Java class files [11, 12]. The numerical libraries wouldbe distributed as class files produced by a Fortran-to-Java translator, f2j. The f2j translatoris a formal compiler that translates programs written using a subset of Fortran 77 into a formthat may be executed on Java virtual machines (JVM).

8 Software re-engineering and modularisation

One of the final stages in updating of legacy software is its re-engineering to use the currentbest practice in language and software design: modules, dynamic arrays, derived data typesare a few of the more modern feature of Fortran 90/95. There are a few tools dedicated tosoftware re-engineering in general but only a very limited number address Fortran. In generalthese programs perform a structural analysis of the software and provide some transformationtools but full automation is not available. Most of the re-engineering - moving the code around- has to be done by the programmer.

A major step in the re-engineering or transformation of Fortran 77 software is modularisation:the grouping of associated routines into collections which are built, developed and USEd by therest of the program as modules. This type of re-engineering is very beneficial in the furtherdevelopment and maintenance of the software. Modularisation allows the software designerto hide selected data and procedures from other elements of the program and in a librarycontext, from the library users and the make available other data elements and procedures. Theprogrammer has detailed control over access to data and procedures within modules by use ofthe PUBLIC and PRIVATE directives.

Using the scoping rules inherent in the process of modularisation the programmer can tailorthe use of dynamic memory management to provide temporary or run time dependent arrays.

Some commercial tools are available for Fortran applications such as FORESYS from SIMULOG[33] and Understand for Fortran from Scientific Toolworks Inc. [31] but none of them willautomatically re-engineer a program into a modular structure.

A pragmatic approach to this initial re-engineering is to use the package’s procedure calltree. This provides the calling relationship between procedures in a program. They give a basicsoftware engineering partitioning of the program. However there are many ways in which aprogram could be modularised. The call tree provides a straightforward starting point. Belowis the call tree of a small program:

1: SEG3P1

2: GETGEO

3: INTEGER_SETOPT gen:SETOPT

4: CHARACTER_SETOPT gen:SETOPT

5: CREATE_REAL_ARRAY gen:CREATE

6: DESTROY_REAL_ARRAY gen:DESTROY

7: CREATE_REAL_ARRAY gen:CREATE [Cycle: see line 5]

8: PRTGEO

9: GETTOP

10: CREATE_INTEGER_ARRAY gen:CREATE

11: DESTROY_INTEGER_ARRAY gen:DESTROY

12: CREATE_INTEGER_ARRAY gen:CREATE [Cycle: see line 10]

13: PRTTOP

14: REAL_MATNUL gen:MATNUL

15

15: INTEGER_SETOPT gen:SETOPT

16: CREATE_REAL_ARRAY gen:CREATE

17: DESTROY_REAL_ARRAY gen:DESTROY

18: CREATE_REAL_ARRAY gen:CREATE [Cycle: see line 5]

19: INTEGER_VECNUL gen:VECNUL

20: CREATE_INTEGER_VECTOR gen:CREATE

21: DESTROY_INTEGER_VECTOR gen:DESTROY

22: CREATE_INTEGER_VECTOR gen:CREATE [Cycle: see line 20]

23: REAL_VECNUL gen:VECNUL

24: CREATE_REAL_VECTOR gen:CREATE

25: DESTROY_REAL_VECTOR gen:DESTROY

26: CREATE_REAL_VECTOR gen:CREATE [Cycle: see line 24]

27: INTEGER_MATNUL gen:MATNUL

28: INTEGER_SETOPT gen:SETOPT

29: CREATE_INTEGER_ARRAY gen:CREATE

30: DESTROY_INTEGER_ARRAY gen:DESTROY

31: CREATE_INTEGER_ARRAY gen:CREATE [Cycle: see line 10]

.........................................................continued

This call tree was generated by the NAGWare tool nag fcalls95. In this particular call tree theuse of generic functions and recursion are indicated by the gen: and Cycle: annotations.

It is reasonably clear from this call tree that there are number of basic routines called by themajority of higher level routines. It would be reasonable to group these into a module. Thisprocess is one of classification and collection with the aim of making the assembled routineseasier to manage and develop.

Grouping on other attributes of a routine is quite in order provided the basic goal of collect-ing together routines with similar attributes leads to a simplification of the development andmaintenance processes.

A useful byproduct of this process of modularisation is the generation of libraries. Each ofthese modules can be viewed as a library of components to be used in building the application.Each module will provide a binary and a module definition file. The module definition file willhold all the information about routine argument lists to be used by the compilation systemduring compilation and building of the executable. This will greatly reduce the incidence ofincorrect argument list and the subsequent difficult run-time bugs.

Clearly these modules are USEd by the application and this requires an ordering of the com-pilation process. Tools like the NAGWare tool nag depend95 analyse the source of a program andgenerate a list of compilation dependencies based on the USE and INCLUDE statements in theprogram. These can be used in make files to ensure the necessary compilation order.

9 Componentisation and encapsulation

As mention above there is much legacy software that is well used and trusted by its communityof users. For such trusted software there can be a great reluctance to even tinker with let alonetransform the code. Any change would appear to reduce the level of trust in the results of thecomputation. Componentisation and encapsulation can be ways in which this trusted softwarecan be migrated into a new computing framework without reducing the package’s level of trust.Some steps to componentisation:

• generate legacy wrapper,

• add interface block,

• build application module,

• apply dynamic memory,

16

US

ER

Object/Abstraction Layer

Wrapper/Interface Layer

Legacy

Software

Dev

elop

men

tO

n−go

ing

Figure 2: Componentisation and Abstraction [4]

• definition of user derived data types,

• and the application of object orientation.

These are ordered in terms of complexity and the level of abstraction and describe a spectrumof re-engineering which the programmer can apply. Figure ?? gives a graphic representation ofthe multiple layers in the componentisation process.

The first step is this process is to encapsulate the software using a simple software wrapper.Generally making the software a module is the simplest approach. The module will contain thelegacy software and define tightly its calling sequence using the interface mechanisms providedin Fortran 90/95. This will ensure that the legacy software is called correctly. This is illustratedin the example below.

The wrapper defines a modern interface to the software and provides a layered abstractionof the code. These layers can then be used to control further modernisation of the code butpreserve the original mostly unmodified programming. These layer will allow development atall levels whilst ensuring a stable user interface to the functionality of the legacy software. anynewer processes of abstraction using user defined data types and object orientation can be builtinto the appropriate levels.

Clearly this approach does not preclude the development of the legacy software. What isimportant as the application level user interface will be clearly defined.

The best way to understand the componentisation process is through a simple example. Weuse a basic Gaussian factorization routine for banded matrices which is written in Fortran 77.The routine can be characterised by:

C

SUBROUTINE GAUSOL(A,IA,JA,AL,IAL,JAL,N,HBAND,ROPIV,IROPIV,R,IR,

* ITEST)

C-----------------------------------------------------------------------

C PURPOSE

C GAUSOL calculates the solution of a set of unsymmetric real

C banded equations with a single rhs using gaussian elimination

C with partial pivoting.

C

C-----------------------------------------------------------------------

C

INTEGER HBAND,IA,IAL,IR,IROPIV,ITEST,JA,JAL,N,ROPIV

DOUBLE PRECISION A,AL,R

DIMENSION A(IA,JA),AL(IAL,JAL),R(IR),ROPIV(IROPIV)

C

17

.............

Code body

C

END

This is the interface to some old, ugly but fast and well trusted legacy software.The first step is to define this interface in such a way that the Fortran 90/95 compilation

system can verify the arguments in this routine call. Within Fortran 90/95 context we definethe routine INTERFACE block.

INTERFACE

SUBROUTINE GAUSOL(a,ia,ja,al,ial,jal,n,hband,ropiv, &

& iropiv,r,ir,itest)

IMPLICIT NONE

INTEGER :: hband,ia,ial,ir,iropiv,itest,ja,jal,n

REAL(R8KIND),DIMENSION(ia,ja) :: a

REAL(R8KIND),DIMENSION(ial,jal) :: al

REAL(R8KIND),DIMENSION(ir) :: r

INTEGER,DIMENSION(iropiv) :: ropiv

INTENT (IN) hband,ia,ial,ir,iropiv,ja,jal,n

INTENT (INOUT) a,al,itest,r,ropiv

END SUBROUTINE GAUSOL

END INTERFACE

This interface block was generated by plusFORT tool spag (a similar tool is available in theNagWare Tools). This interface block can be included in any Fortran 90/95 program and it willensure that the actual argument list used in the program conforms to the required argument list.The INTERFACE block is a very important Fortran 90/95 mechanism for accurately describingexternal libraries.

The next step in the component transformation will be the construction of a Fortran 90/95wrapper for the legacy code. This will provide the Fortran 90/95 interface to the code. Itsdesign will clearly depend on the legacy code. In this example we refine the routine’s argumentlist by using assumed shape arrays and making some of the arguments optional. Argumentssuch as IA and JA will be unnecessary as they can be derived from the shape and size of theactual arguments. In the most extreme case only the matrix A and the right hand side vectorwill be required as all the other data can be derived from the matrix size. The result is alsoreturned through the vector R. So the Fortran 90/95 calling sequence could be reduced to:

CALL GAUSOL(A,R)

This assumes that only one right hand side requires solution. The wrapper would generate thenecessary working space for AL and ROPIV and could allow a variety of optional arguments. Forexample:

MODULE mod_gausol

USE felib_globals, ONLY : wp

PRIVATE

PUBLIC gausol

CONTAINS

SUBROUTINE gausol(a,r,al,n,hband,ropiv,itest)

18

IMPLICIT NONE

! Dummy arguments

INTEGER, OPTIONAL :: hband, itest, n

REAL (KIND=WP), DIMENSION (:,:) :: a

REAL (KIND=WP), DIMENSION (:) :: r

REAL (KIND=WP), OPTIONAL, DIMENSION (:,:) :: al

INTEGER, OPTIONAL, DIMENSION (:) :: ropiv

INTENT (IN) hband, n

INTENT (INOUT) a, al, itest, r, ropiv

! Local variables

INTEGER :: ia, ial, ja, jal, iropiv, ir

INTEGER :: loc_hband, loc_itest, loc_n

INTEGER, ALLOCATABLE, DIMENSION (:) :: loc_ropiv

REAL (KIND=WP), ALLOCATABLE, DIMENSION (:,:) :: loc_al

! Check optional arguments and create arrays as necessary

loc_n = size(a,1)

IF (present(n)) loc_n = n

loc_hband = size(a,2)

IF (present(hband)) loc_hband = hband

loc_itest = 0

IF (present(itest)) loc_itest = itest

IF (present(al)) THEN

ALLOCATE (loc_al(size(al,1),size(al,2)))

loc_al = al

ELSE

ALLOCATE (loc_al(size(a,1),size(a,2)))

END IF

IF (present(ropiv)) THEN

ALLOCATE (loc_ropiv(size(ropiv,1)))

loc_ropiv = ropiv

ELSE

ALLOCATE (loc_ropiv(size(a,1)))

END IF

! Call to legacy code

ia = size(a,1)

ja = size(a,2)

ial = size(loc_al,1)

jal = size(loc_al,2)

iropiv = size(loc_ropiv,1)

ir = size(r,1)

CALL f77_gausol(a,ia,ja,loc_al,ial,jal,loc_n,loc_hband,loc_ropiv,iropiv,r, &

ir,loc_itest)

IF (present(itest)) itest = loc_itest

IF (present(al)) al(1:ial,1:jal) = loc_al

IF (present(ropiv)) ropiv(1:iropiv) = loc_ropiv

19

END SUBROUTINE gausol

END MODULE mod_gausol

In this example the Fortran 77 version of the gausol subroutine (now called f77 gausol) iswrapped in a Fortran 90/95 wrapper. The new module allows the very truncated calling sequenceto be used. The more complete version of this module would also contain an interface block forf77 gausol which would completely specify the argument list of the Fortran 77 routine.

Although this code will compile and execute on most compilers so will flag the use of theoptional arguements in the SIZE function as an error.

10 Vectorisation and parallelisation tools

Automatic parallelisation has always been the ultimate goal of compiler developers. Howeverthe transformation of legacy software to Fortran 90/95 making use of the array facilities inFortran 90/95 must be the initial goal. This can be a very time consuming task - identifying thepotential inner loops and their associated array variables - identifying any loop level dependanciesand recurrence relationships.

There are very few tools that can aid the programmer in this task and only a few vendors thatprovide compilers that seek to provide automatic parallelisation. One of the few vectorisationtools is VAST/77to90 from Crescent Bay Software [20] is a Fortran 77 to Fortran 90/95 translator.Crescent Bay Software provide an innovative metered licensing system where you pay for onlythe amount of code translated.

An example of VAST/77to90’s processing is shown below (taken from the Crescent Bay Soft-ware Web site). Given the following Fortran 77 input:

subroutine demo(a,b,c,n)

dimension a(n), b(n), c(n)

common /ecom/scratch(10000)

do 100 i = 1, n

a(i) = b(i) + c(i)

if ( a(i).gt.100.0) then

a(i) = a(i) + scratch(i)

go to 100

endif

c(i) = a(i)*2

100 continue

end

VAST/77to90 created a Fortran 90/95 module:

module Vecom

real, dimension(10000) :: scratch

end module Vecom

and a re-structured main program

subroutine demo(a, b, c, n)

!---------------------------

! Modules

!---------------------------

USE Vecom

implicit none

!---------------------------

! Dummy Arguments

!---------------------------

integer n

real, dimension(n) :: a, b,c

20

!---------------------------

! Local Variables

!---------------------------

integer :: i

!---------------------------

a = b + c

where (a > 100.0 )

a = a + scratch(:n)

elsewhere

c = a*2

end where

end subroutine demo

In is very important to note that VAST/77to90 has identified arrays where the Fortran 90/95array syntax could be utilised and transformed the code suitably.

There have only been few tools to aid the parallelisation process; examples include VAST/toOpenMP[20], VAST/Parallel [20], ParaWise (CAPTools) [21], WPIPS [22] and POLARIS [23]. These ingeneral produce a source to source transformation using dependency analysis.

The major aids to parallelisation have been the specially developed libraries or tool sets suchas ScaLAPACK [24] or PETSc [25, 26]. These libraries will provide parallel functionality at thecost of using a specific programming model and in-built data structures.

Although many applications are now designed to make use of MPI there are still many legacyprograms that would benefit the community if they were available on services such as HPCx[39] and CSAR [40].

11 Memory leakage detection

One of the major sources of difficulty in using dynamic arrays in Fortran 90/95 is memoryleakage. Without a very careful count of ALLOCATES and DEALLOCATES it is very easy for leaksto arise.

Normally, it is the operating system that takes responsibility for allocating and deallocatingstorage to (static) variables. However, when using dynamic arrays this responsibility falls tothe programmer. Statements like ALLOCATE and DEALLOCATE are very powerful. Storage allo-cated through the ALLOCATE statement may only be recovered by a corresponding DEALLOCATE

statement or by the program terminating.Storage allocated to local variables (in a subprogram or function, say) must be deallocated

before exiting the procedure. When leaving a procedure all local variables are deleted frommemory and the program releases any associated storage for use elsewhere. However, anystorage allocated through the ALLOCATE statement will remain in use even though it has noassociated variable name. Storage allocated, but no longer accessible, cannot be released orused elsewhere in the program and is said to be in an undefined state This reduction in the totalstorage available to the program is called a memory leak.

SUBROUTINE swap(a, b)

REAL, DIMENSION(:) :: a, b

REAL, ALLOCATABLE :: work(:)

ALLOCATE( work(SIZE(a)) )

work = a

a = b

b = work

DEALLOCATE( work ) ! necessary

END SUBROUTINE swap

The automatic arrays a and b are static variables - the program allocates the required storagewhen swap is called and deallocates the storage on exiting the procedure. The storage allocatedto the allocatable array work must be explicitly deallocated to prevent a memory leak. Memory

21

leaks are cumulative. Repeated use of a procedure which contains a memory leak will increasethe size of the allocated, but unusable, memory. Memory leaks can be difficult errors to detectbut may be avoided by remembering to allocate and deallocate storage in the same procedure.

There are a variety of tools available to detect memory leaks. Various compilers have optionsto provide this tracing at run time and there are various stand alone tools performing the sametask. Most of these tools have been developed for C and C++ programs and not Fortran 90/95.However many of them will provide useful information when applied to Fortran 90/95 programs.

Two of these tools are: memprof [27] and valgrind [28].The programs are freely available over the Internet from

http://www.gnome.org/projects/memprof/

and

http://valgrind.kde.org/index.html

and are easily installed and used. Two features of memprof worth noting are:

• It can generate a profile of how much memory was allocated by each function in yourprogram.

• It can scan memory and find blocks that you have allocated but are no longer referencedanywhere.

memprof works by pre-loading a library to override the C library’s memory allocation functionsand does not require you to recompile your program.

One advantage memprof has over some other similar tools that are available, such valgrind,is that it has a GUI front-end and is relatively easy to use. It appears to work fine on Fortranprograms although its diagnostic output, using instruction addresses, is not particularly useful.It does however give a useful way of indicating the presence of memory leaks.

Similarly valgrind works fine with C and C++ and produces some useful information whenused on Fortran program although the output is quite cryptic.

12 Maintaining quality

Computer science has devised many models of the software life-cycle. The cycle can be looselydefined as the phases a software product goes through between when it is conceived and when itis no longer available for use. There are many different models of this process. The Classical LifeCycle Model or Linear Sequential Model typically includes the following activities: requirementsanalysis, design, construction, testing (validation), installation, operation, maintenance, andretirement.

The development process tends to run iteratively through these phases rather than linearly;several models (spiral, waterfall etc.) have been proposed to describe this process. Other pro-cesses associated with a software product are: quality assurance, marketing, sales and support.The transformation and re-engineering of legacy software does not really fit into these mod-els. However since the process is often iterative and cyclic, legacy re-engineering or softwaremodernisation could be viewed as starting the cycle again with new requirements.

The whole process is a costly occupation in software licenses, computing time and mostimportantly human resources. At the end of the process the intellectual property encapsulatedin the original software is now available through re-generated software and can also be developedfurther.

The process of assessing the quality of a large software package in full and making remedialdevelopments is very daunting however once done initially the process of maintaining the softwarequality does not have to be a high consumer of resources. Given a suitable software development

22

process and access to a small number of suitable tools, maintaining the attained level of qualityshould be no more complex a task as running a compiler or placing a component back in CVS.

Checking the source language quality of a particular component should only require runninga short series of QA checks: acting on the results of these check might required some work butthe majority of the work should have been done at the design and implementation phases ofthe component. The better compilers give excellent diagnostic checks on language conformance.However tools such as the NAGWare nag modules95 and FORCHECK [29] from Lieden Universityare designed for this task. Each of these tools will reported on any misuse of the Fortran 90/95standard. As an aid to portability FORCHECK provides an compiler emulation mode for a greatmany commonly used compilers.

These tools provide an assessment of conformance but not of quality. There are very fewtools that attempt to provide a comprehensive set of measures of software quality. QA Fortran[30] from Programming Research Ltd, Understand for Fortran [31] from Scientific ToolworksInc. and the McCabe IQ Toolset [32] from McCabe & Associates are some of the few.

Testing the component in the context of the whole package is another problem. Quality atthis point relies on the testing processes being adopted. Regression testing using a set of datathat provides adequate coverage is basic. Ensuring adequate coverage is a difficult problem.There are many tools for instrumenting programs to provide a dynamic coverage analysis. Thispart of software quality can be very computationally intensive but is essential in ensuring qualitysoftware.

13 Conclusions

In this report we have considered some difficulties in preserving the intellectual property encap-sulated in the software generated by research projects. We have proposed a pragmatic processof rescuing such software and making it available to future development programmes.

We have also given some details of the process and the software tools that could be used inassessing and maintaining the quality of research software.

It is recognised that this is only a very basic level of software engineering and that there aremany gains to be made for the Fortran programmer if the process of legacy software transforma-tion is followed by the adoption of some good processes in maintaining software quality throughmetric monitoring and comprehensive regression testing.

23

References

[1] S.I. Feldman and P.J. Weinberger, ‘A Portable Fortran 77 Compiler’, UNIX Time SharingSystem Programmer’s Manual, Tenth Edition, Volume 2, AT&T Bell Laboratories, 1990.

[2] V.K. Decyk, C.D. Norton and B.K. Szymanski, ‘How to support inheritance and run-time polymorphism in Fortran 90’, Computer Physics Communications, 115:9-17, December1998.

[3] V.K. Decyk, C.D. Norton and B.K. Szymanski, ‘How to Express C++ Concepts in Fortran90’, Scientific Programming, 6(4):363-390, Winter 1997. IOS Press.

[4] V.K. Decyk and C.D. Norton, ‘Modernizing Fortran 77 Legacy Codes’, NASA Tech Briefs,Vol. 27, No. 9, pp. 72, September 2003.

[5] V.K. Decyk and C.D. Norton. ‘Modernizing Fortran 77 Legacy Codes’, In Conference onComputational Physics 2000 (CCP 2000), Advance Program and Technical Digest, GoldCoast, Queensland, Australia, pg. 104, December 3-8 2000.

[6] Tata Infortech, ‘Legacy Modernization Approaches fro Unisys Clearpath IX’, Companyreport, 2002

[7] E. Akin, ‘Object-Oriented Programming via Fortran 90/95’, Cambridge University Press,2003

[8] F.B. Bashir, ’What is Legacy Software’, http://www.suite101.com/article.cfm/751/9540

[9] Cobalt Blue: FOR C, FOR STRUCT http://ww.cobalt-blue.com

[10] ’Fortran 95 Part 3 - Conditional Compilation’, ISO/IEC 1539-1:1997

[11] D.M. Dooling, J. Dongarra and K. Seymour, ’JLAPACK-Compiling LAPACK FORTRANto Java in Scientific Programming, 7(2), 111-138, 1999

[12] K. Seymour and J. Dongarra, ’Automatic Translation of Fortran to JVM Bytecode’ pre-sented at the Joint ACM Java Grande/ISCOPE conference in Palo Alto, CA on June 3,2001.

[13] J.D. Ahrens and N.S. Prywes, ’Transition to a Legacy- and Reuse- Based Software LifeCycle’, Computer, October 1995

[14] Sun Microsystems Inc, The Java Language Environment, Sun Microsystems, MountainView, CA, 1995

[15] M. Metcalf and J. Reid, Fortran 90/95 explained, Oxford University Press, 1999

[16] P. Andrews, G. Cats, D. Dent, M. Gertz and J.L. Ricard, ”EuropeanStandards for Writing and Documenting Exchangeable Fortran 90 Code”,http://www.meto.gov.uk/research/nwp/numerical/fortran90/f90 standards.html,1996

[17] J.K. Prentice, ’Automatic Translation of Fortan 77 to Fortran 90 using VAST-90’, FortranJournal, vol 5, No 4, 1993

[18] PROMULA Development Corporation (PDC), http://www.promula.com

[19] f2c Fortran to C translator, http://www.netlib.org/f2c/readme

[20] Crescent Bay Software, http://www.crescentbaysoftware.com/

24

[21] Parallel Software Products Inc. (ParWise/CAPTOOLS), http://www.parallelsp.com/

[22] WPIPS - an open and extensible workbench for automatically analysing software,http://www.cri.ensmp.fr/people/pips/index.html

[23] POLARIS - Automatic Parallelization of Conventional Fortran Programs,http://polaris.cs.uiuc.edu/polaris/polaris-old.html

[24] ScaLAPACK - linear algebra for dense and band matrix systems,http://www.netlib.org/scalapack/scalapack home.html

[25] Satish Balay, Kris Buschelman, Victor Eijkhout, William D. Gropp, Dinesh Kaushik,Matthew G. Knepley, Lois Curfman McInnes, Barry F. Smith, and Hong Zhang,“PETScUsers Manual”,Argonne National Laboratory, ANL-95/11 - Revision 2.2.0, 2004.

[26] PETSc- Portable, Extensible Toolkit for Scientific Computation,http://www-unix.mcs.anl.gov/petsc/petsc-2/

[27] memprof - Profiling and leak detection, http://www.gnome.org/projects/memprof/

[28] Valgrind for debugging and profiling x86-Linux programs http://valgrind.kde.org/

[29] Forcheck - A Fortran analyzer and programming aid, http://www.forcheck.nl/

[30] QA Fortran

[31] understand Fortran

[32] McCabe IQ Toolset

[33] FORESYS from SIMULOGUE

[34] Numerical Algorithms Group Ltd. - NagWare Tools

[35] Ian Hounam and Stuart Hemstock, ”‘Migrating from Fortran 77 to Fortran 90 with theNAGWare f77 and f90 Tools, Numerical Algorithms Group Ltd, Oxford

[36] Polyhedron Software - plusFORT

[37] software tools report?

[38] tools for HEC?

[39] HPCx Capability Computing Service, http://www.hpcx.ac.uk

[40] National High Performance Computing (HPC) service , http://www.csar.cfs.ac.uk/

25

A Some transformation tools

There is a good selection of tools to help the programmer in transforming his software. The firststep is often the hardest: is my program really Fortran 77 or Fortran 90/95? - the problem ofconformance to a single language standard. It is often the case, in academic research projects,that the software developed is a arbitrary mixture of various Fortran standards, styles and exten-sions. Each of the tool suites below will help in getting a program into a single language dialect.Some of them provide a Fortran 77 to Fortran 90/95 translation (only really a format change)and additional functionality to convert COMMON blocks and INCLUDE files into MODULES togetherwith utilities to generate INTERFACE blocks. Although some of them attempt a restructuring ofthe software to remove some of the undesirable features of Fortran 77 none will generate memoryallocation directives or identify places where the Fortran 90/95 array syntax can be used. Twogroups of tools have been heavily used to good effect in the current moderisation work: theNAGWare tools from the Numerical Algorithms Group Ltd. and plusFORT tools from PolyhedronSoftware.

A.1 Numerical Algorithms Group Ltd. - NAGware tools

The NAGWare tools [34, 35] provide a comprehensive set of software tool to help the programmermove from Fortran 77 to Fortran 90/95 and to subsequently maintain the software’s languageconformance. In the past NAG Ltd. has provided software tools for analysis and transformationof Fortran 77 software both as the outputs of the TOOLPACK project and as a more customisedNAGWaretool set. They now offer the NAGWare Tools which contain a similar set of tools for bothFortran 77 and Fortran 90/95. Not all tools are available for each form of Fortran but thereis good commonality between the tools. These can be run through a GUI which allows easyselection of the source files and operations to perform on them and through a command lineinterface. The individual tools available include the following:

Polish - for pretty printing source code (standardisation of the source form). This includesconsistent indentation of loops and conditional statements. Keywords and variables canbe individually mapped to upper or lower case to enhance readability. A graphical interfaceallows simple editing of the formatting options.

Declaration standardisation - this splits up the declarations into groups and reorganisesthem into a standard form for easier understanding. Clear comment sections separatescalar arguments from array arguments, local scalars, etc.

Name changer - to alter variable and subprogram names consistently throughout a body ofcode. This allows variable names to be changed to more meaningful strings. It offers asafer conversion process than global edits which might change unintended substrings.

Dependency analysis - generates makefiles for a set of Fortran 90/95 files. With the additionof modules to the language, combined with the existing problem of INCLUDE files, it is acomplex task to include all file dependencies in a makefile. This can lead to difficult-to-findproblems when out of date modules are used by mistake. This tool generates a full set ofdependency rules from the selected Fortran files.

Call graph generator - this generates a traditional call tree for a given set of Fortran 90/95files,as an aid to documentation and understanding of the software.

Interface builder - this creates explicit interface blocks for Fortran routines which currentlyonly use implicit ones. This enables the Fortran 90/95 compiler to do much more argumentchecking of procedure calls. A new module file containing the interface blocks can begenerated and appropriate USE statements are inserted in the calling routines. The ONLY

qualifier is added to the interface block USE statement so that it is clear which routine(s)

26

have been defined. In the case of calls to library routines, which are not defined in thecode, interface blocks can still be generated, though the user must check that these areindeed correct.

USE statement annotator - this can add appropriate ONLY clauses to USE statements. Thismakes the way data is imported more explicit to anyone reading the code. It also reducesthe chances of subsequent updates to the software using module variables by mistake.

A similar set of NAG tools is available for Fortran 77 software. These include a restructuringtool nag structwhich attempts to replace old style coding with more readable structures suchIF-THEN-ELSE blocks.

With the two sets of Fortran tools comes a converter from Fortran 77 to Fortran 90/95nag trans. This includes a graphical user interface and takes advantage of the new free formatand declaration style of Fortran 90/95.

These tools should provide a good path for transforming old Fortran software to Fortran 90/95using a well structured and easy to read format. The addition of explicit interfaces to allsubprogram calls should significantly increase the confidence in the quality of the software, asit allows immediate detection of linkage errors. The addition of restructuring and commonconversion tools should enhance the usefulness of this product.

A.2 Polyhedron Software Ltd - plusFort tools

plusFORT from Polyhedron Software [36] consists of a set of tools for Fortran analysis checking.The tools currently available in Version 6 are:

plusFORT spag - As well as Fortran 66 to Fortran F77 conversions, this tool is able to convertFortran 77 code to use some Fortran 90/95 constructs, such as DO-WHILE, ENDDO, CYCLE,EXIT, etc. spag can also remove dead code and unused variables as well as code polishingand standardisation of declarations. The intent of all arguments can also be added to thereformatted code.

Global symbol tables can be produced for further analysis, using GXCHK (see next section).Some limited complexity metrics can be determined for each subprogram. The measuresreported are: logical content (number of decision points, comparable to McCabe), allcontrol jumps, where control is transfered to another point, and unstructured jumps. Therestructuring of SPAG can often reduce the last two measures.

plusFORT Static Analysis - A full global static analysis can be performed using GXCHK. Thisuses the symbol tables which are generated by spag. It provides checking for variablesused before set, argument mismatch, common block problems, etc. It can also generateinterface specifications for each subprogram. Call trees and charts showing where variablesare used may be produced.

plusFORT Dynamic Analysis - Dynamic analysis is made possible by using spag to addrun time checking statements to the code. Used before set errors, including tests on arrayelements, are checked in the modified code. The instrumented code is run in the normalway and produces a log file of any faults.

plusFORT Coverage Analysis - The program CVRANAL can be used to instrument Fortransoftware for coverage analysis. A report is produced as to how often each block has beenexecuted in the test runs. A cumulative count of the times each block is executed can bemade over several runs. CPU time profiling can also be performed.

plusFORT Automake - This automatically checks for dependencies via INCLUDE and USE

statements to rebuild an executable file. It is Fortran 90/95 aware.

27

While many Fortran 90/95 features are mentioned in the documentation, the emphasis is onFortran 77 code. The documents do not discuss the use of MODULEs, TYPEs or POINTERs.The introduction to the software describes it a converter to structured Fortran 77 with Fortran 90extensions. It does, however, support F90 source form, declarations and operators.

A.3 Leiden University FORCHECK

Forcheck Group at Leiden University [29] have been developing FORCHECK for a large numberof years. FORCHECK supports Fortran 77, Fortran 90/95 and High Performance Fortran. It alsosupports many popular extensions. The tool provides:

• Call tree generation;

• Cross reference tables for variables, subprograms, common blocks, etc.;

• Source code listing with error and warning messages inserted.

• Inter-procedure argument checks;

• Static checks for variables used before set, unused variables, etc.;

• A summary report of the code analysis;

A wide range of compilers (and most of their extensions) are supported through an emulation.These include Cray, IBM, DEC, SGI and SUN Fortran 90 compilers. Several Fortran 95 com-pilers, such as those from Lahey and Salford, are also supported. The software runs on manydifferent Unix systems as well as DOS and Microsoft Windows. A graphical user interface isavailable on some systems and a command line interface on all systems.

A.4 Understand for Fortran

Understand for FORTRAN is an interactive development environment (IDE) tool providing re-verse engineering, automatic documentation, metrics and cross referencing of FORTRAN sourcecode. It supports FORTRAN 77 (F77) and FORTRAN 90 (F9X) language standards, with com-mon VAX, Cray and Salford extensions. Understand for FORTRAN helps you reverse engineer,understand and maintain large amounts of legacy FORTRAN source code. The tool includesa syntax colorizing ”smart” editor that can tell you about what you are editing. It also in-cludes numerous graphical reverse engineering views designed to help you understand and assesschanges you are considering in your code.

Understand for FORTRAN offers in-depth graphical reverse engineering, fast code navigation,detailed cross referencing, interactive source browsing, automatic documentation via HTMLoutput reports, various complexity and volume metrics, as well as easy integration with outsideeditors. A PERL API and C/C++ API are included so that you can write scripts and programsgenerating automatic documentation directly from your source code. Understand for FORTRANis a source code analyzer; it helps programmers understand their FORTRAN software projects.

Understand for FORTRAN analyzes your FORTRAN software to create a repository of therelations and structures contained within it. The repository is then used to learn about thesource code.

Understand for FORTRAN helps you quickly answer questions such as:

• What is this entity?

• Where is it changed?

• Where is it referenced?

• Who depends on it?

28

• What does it depend on?

Understand for FORTRAN answers these questions through interactive entity specific crossreference reports and graphical diagrams quickly showing the relevant information about a givenentity.

A.5 Simulog FORESYS

The Simulog FORESYS product (FORtran Engineering SYStem) is a set of five tools that coveranalysis, inspection, restructuring, parallelisation and interfacing to CASE tools. The individualcomponents are:

ADMIN : a Fortran 77 analyser. This tool provides global checking of subprogram inter-faces and common blocks. The use of un-initialised variables and sections of unused codearereported. It also creates a database of the analysed program for use by other tools.

IDCM : a tool to examine Fortran source code. This allows the user to browse the Fortran77 source code, highlighting errors detected by the ADMIN tool. It also allows interactivegeneration of restructured source in either Fortran 77 or Fortran 90 forms using FOREST.

FOREST : a restructuring tool, including Fortran 77 to 90 conversion. This allows codeto be restructured to either Fortran 77 of Fortran 90. Conversion includes use of newdeclarations, SELECT -CASE, etc. Explicit interfaces can be generated in a separatemodule. Argument INTENT statements can also be added.

PARTITA : a parallelisation tool. This includes analysis of data flow within existing Fortran77 code to generate Fortran 90 ( or 77) code with good parallel and vector performance.

FORESYS/REV : an interface to the Teamwork/SD CASE tool. This allows high levelstructural analysis of the source code, including generation of call graphs, etc.]

All these tools can make use of a graphical user interface. Though they can be used to convertold code to the new standard, the documentation seems to indicate that the analysis tool canonly be used on Fortran 77 code. Supported systems include Sun Solaris, SGI IRIX, IBM A IX,HP-UX and DEC Alpha OSF/l. 25

A.6 QA Fortran

A.7 McCabe IQ Toolset

A.8 VAST/77to90 from Crescent Bay Software [20]

VAST/77to90 from Crescent Bay Software is a Fortran 77 to Fortran 90 translator that allowsyou to upgrade your existing Fortran 77 programs to a higher level. Whether you are justlearning to write Fortran 90 programs or have already become a Fortran 90 expert, you will findthat VAST/77to90 is the right tool to enhance your applications. In addition, with its innovativemetered licensing system, you pay for only the amount of translation that you need.

With VAST/77to90 you can easily update all your existing Fortran 77 programs to cleanand efficient Fortran 90. This is much more than a source form reformatter. For example,VAST/77to90’s sophisticated Fortran 90 capability provides automatic generation of multi-dimensional array syntax. Developed over many years in Crescent Bay Software’s VAST-Fproduct line, this capability was first delivered to users in 1985, and has been used extensivelyby many computer manufacturers.

Some of the conversions performed by VAST/77to90:

• Generation of new source form

29

• Removal of obsolete features

• Elimination or reduction of GOTOs and labels

• Generation of array syntax in place of loops.

• Creation of MODULEs from COMMONs

• Automatic generation of interface blocks.

• Fortran ”lint” diagnostics

VAST/77to90 is priced on a metering basis. This means that you pay for only as many linesas you need.

30

B Language translation

The two examples detailed below are of transforming conforming Fortran 77 to ANSI C usingthe PROMULA and f2c translators.

B.1 PROMULA Fortran to C translator/compiler - http://www.promula.com

This tool translates FORTRAN source code to correct (compilable) and clean (readable andmaintainable) C source code. It is intended for those who wish to convert their FORTRANcodes to C automatically; 100 percent conversion rates are achieved routinely.

The conversions yield reproducible results and are repeatable and verifiable. A number ofinput FORTRAN dialects are supported via a dialect definition flag, and the form of the outputC code is controlled by a multitude of command-line switches. The translations are so completeand correct that the tool may also be used in conjunction with a standard C Compiler as ageneral-purpose, multi-dialect and portable FORTRAN compiler.

It runs on multiple platforms and supports both the ANSI FORTRAN 66 and ANSI FOR-TRAN 77 standard dialects, as well as a large number of extensions found in various commercialFORTRAN compilers. The following FORTRAN dialects are supported: VAX, PDP, SUN, HP,CRAY, PRIME, Data General, UNISYS, and Honeywell. Some FORTRAN 90 extensions arealso supported. With this product, existing FORTRAN applications will compile on ”open”platforms as is, i.e., without making any changes to the original FORTRAN source code.

Validated by the GSA FORTRAN Compiler Validation Test Suite, the compiler works bytranslating FORTRAN source code to C source code (from where it derives its portability).It requires a C compiler/linker to produce executable code and is the ideal processor for hy-brid FORTRAN/C applications. Symbolic FORTRAN debugging is supported by the symbolicdebugger of the host C platform (e.g., the dbx tool for UNIX platforms).

The product includes both the translator/compiler and an extensive FORTRAN Run-timeLibrary (about 300 functions written in portable C source code). The run-time library may belinked into your executables for royalty-free distribution.

The output from PFC does not look like machine translation. To present some of the designfeatures of the translator, consider the following example program which computes the meanand variance of a set of values.

C

SUBROUTINE EX001(VAL,N,XBAR,VAR)

C

C*** Start of declarations

C

C Dummy arguments

C

INTEGER N

REAL VAR , XBAR

REAL VAL(N)

C

C Local variables

C

INTEGER J

REAL S

C

C*** End of declarations

C

XBAR = 0.0

VAR = 0.0

DO 100 J = 1 , N

XBAR = XBAR + VAL(J)

100 CONTINUE

31

XBAR = XBAR/N

DO 200 J = 1 , N

S = VAL(J) - XBAR

VAR = VAR + S*S

200 CONTINUE

VAR = VAR/(N-1)

RETURN

END

produces the following C output

void ex001(val,n,xbar,var)

int n;

float *val,*xbar,*var;

{

auto int j;

auto float s;

*xbar = *var = 0.0;

for(j=0; j<n; j++) *xbar += *(val+j);

*xbar /= n;

for(j=0; j<n; j++) {

s = *(val+j)-*xbar;

*var += (s*s);

}

*var /= (n-1);

}

The following notes should be noted:

1. that the parameter n is not declared as a pointer, since it is not changed within theroutine. PFC uses what are called prototypes of subprogram arguments so that it cangenerate optimal calling sequences. These prototypes may be specified by the user or maybe determined internally by the translator. The above was internally determined by thetranslator.

2. that C allows multiple assignments to the same value to be written together. The translatorlooks for such assignments and combines them whenever possible.

3. that in FORTRAN the default base for a subscript is 1. Thus, all do loops which generatesubscripts tend to start at 1. In C, however, subscripts start at zero. This fact makes formuch more efficient code. The translator looks for do loops whose only purpose is to movethrough array subscripts and reduces their range to start at zero, thus producing a verynatural looking for-statement and optimizing subscript expressions.

4. that C has ++ and operators which take advantage of the fact that most computershave increment and decrement operators. The translator uses these operators wheneverpossible.

5. that C has operators like +=, -=, *=, /=, etc. The use of these operators ensures that theaddress of the left-hand-side of the assignment will only be computed as often as necessary.PFC uses these operators.

6. that the do loop running to statement 10 in the FORTRAN code is collapsed into a singlecompound statement, and that the now unneeded statement label is removed.

7. that though the do loop statements in loop 15 cannot be reduced to a single statement,the statement label can still be removed.

32

B.2 f2c - Fortran 77 to C translation [1]

Another translation program is the f2c. f2c will in general translate Fortran 77 into correctANSI C. However, as one might expect, the translation tends to obscure the original Fortran.The output of f2c using the same input as Section B.1 is shown below.

/* prog.f -- translated by f2c (version 20000121).

You must link the resulting object file with the libraries:

-lf2c -lm (in that order)

*/

#include "f2c.h"

/* Subroutine */ int ex001_(val, n, xbar, var)

real *val;

integer *n;

real *xbar, *var;

{

/* System generated locals */

integer i__1;

/* Local variables */

static integer j;

static real s;

/* *** Start of declarations */

/* Dummy arguments */

/* Local variables */

/* *** End of declarations */

/* Parameter adjustments */

--val;

/* Function Body */

*xbar = (float)0.;

*var = (float)0.;

i__1 = *n;

for (j = 1; j <= i__1; ++j) {

*xbar += val[j];

/* L100: */

}

*xbar /= *n;

i__1 = *n;

for (j = 1; j <= i__1; ++j) {

s = val[j] - *xbar;

*var += s * s;

/* L200: */

}

*var /= *n - 1;

return 0;

} /* ex001_ */

33

The basic difficulties with this type of automatic translation are clear to see. This output is notreally a good starting point for developing in the new language.

Although not particularly useful in this context f2c is now generally distributed with thestandard installation of Linux and has made important contribution to those without access toFortran 77 compilers.

B.3 The f2j project

The Java programming language [14] has grown dramatically in popularity in recent years inboth industry and academia. It has current found its role in Web programming and GUIs butnow some interest is being shown in the language for high-performance and scientific applica-tions. One very serious attempt to exploit Java in a computational context has been the f2j

project. The primary motivation of the f2jproject is to provide numerical linear algebra soft-ware originally written in Fortran as Java class files [11, 12]. The numerical libraries would bedistributed as class files produced by a Fortran-to-Java translator, f2j. The f2j translator is aformal compiler that translates programs written using a subset of Fortran 77 into a form thatmay be executed on Java virtual machines (JVM). The first priority of f2j is to translate theBLAS and LAPACK numerical libraries from their Fortran 77 reference source code to Java classfiles.

The f2j project is composed of three phases:

• Writing a Fortran front-end capable of lexing and parsing the subset of Fortran necessaryto translate BLAS and LAPACK.

• Generating Java source and JVM bytecode to produce class files for use with a JVM.

• Testing, documenting and distributing the translated BLAS and LAPACK class files.

• Extending the compiler to handle a wider subset of Fortran code.

All of the double precision BLAS and LAPACK Fortran source codes have been translateddirectly to Java sources. The JVM instruction set provides a straightforward method to translateFortran GOTO statements. Since Fortran 77 does not specify while loops, these are implementedin BLAS and LAPACK using GOTO statements, which are supported at the JVM level.

Clearly, as with any translation, efficiency is of great importance to the computational scien-tist. The f2j has performed some initial efficiency tests. The source of the Fortran 77 Linpackbenchmark has been transformed and compared with optimised and unoptimised Fortran 77.Table 2, taken from [12], shows the results of the comparison. The f2j project has a good web

Compilation Method Command line Raw Performance Relative Performance

Optimised Fortran f77 -03 34.7 1.00

Unoptimised Fortran f77 14.1 0.41

Bytecode f2java 10.9 0.31

Java Source f2java; javac 10.3 0.30

Java Source Optimised f2java; javac -O 10.3 0.30

Table 2: Performance on the double-precesion Linpack Benchmark (n = 500)

site at http://www.cs.utk.edu/f2j/.

34

C Vectorisation and parallelisation tools

Automatic parallelisation has always been the ultimate goal of compiler developers but in thetransformation of legacy software to Fortan 90/95 making use of the array facilities must aninitial goal. For of the few is the VAST/77to90 which also transforms legacy Fortran 77 toFortran 90/95. There are very few tools that can aid the programmer in this task and onlya few vendors that provide compilers that seek to provide automatic parallelisation. Similarlythere have only been few tools to aid the parallelisation process; examples include ParaWise(CAPTools), WPIPS and POLARIS. These in general produce a source to source transformationusing dependency analyses.

The major aids to parallelisation have been the specially developed libraries or tool sets suchas ScaLAPACK or PETSc. These libraries will provide parallel functionality at the cost of usinga specific programming model and in-built data structures.

Although many applications are now designed to make use of MPI there are still many legacyprograms that would benefit the community if they were available on machines such as HPCx.

C.1 Crescent Bay Software - VAST/77to90

VAST/77to90 is developed and marketed by Crescent Bay Software and is a Fortran 77 toFortran 90/95 translator. VAST/77to90 can be used to update existing Fortran 77 programs toclean Fortran 90/95. It is more than a basic source form reformatter. For example, VAST/77to90provides automatic generation of multi-dimensional array syntax. Some of the conversions per-formed by VAST/77to90:

• Generation of new source form

• Removal of obsolete features

• Elimination or reduction of GOTOs and labels

• Generation of array syntax in place of loops

• Creation of MODULEs from COMMONs

• Automatic generation of interface blocks

• Fortran ’lint’ diagnostics

A review of VAST/77to90’s Fortran 77 to Fortran 90/95 conversion capabilities has been pub-lished in the July/August 1993 issue of Fortran Journal [17].

VAST/77to90 is charged on a metering basis and not a simple license. This means that youpay for lines of code processed.

C.2 Parallel Software Products Inc. - ParaWise

ParaWise has been developed primarily to aid in the parallelization of existing serial Fortran 77or Fortran 90 computational mechanics software. ParaWise generates either parallel source codecontaining message passing library calls or OpenMP shared memory directives.

For a code parallelization that uses message passing calls, ParaWise analyzes the serial codeand, with user interaction, generates parallel Fortran version (depending on the original serialcode) which is very similar to the original serial code but with communication calls insertedand modifications to the code that will allow it to run on a parallel system. At every stage ofthe parallelization process, the various ParaWise browsers not only present information to helpthe user understand what has been done, but also provide facilities that allow the user to makemodifications to improve the quality of the parallel code.

35

For a code parallelization that uses OpenMP directives, ParaWise analyzes the serial code andwith user interaction generates Shared Memory directive-based code. The main components ofParaWise are:

• ParaWise uses powerful, state of the art dependence analysis techniques.

• In depth interprocedural analysis using symbolic algebra techniques

• GUI interactive front end

• Generates Shared Memory directive code using OpenMP after the analysis stage.

• Automatic user directed array partitioning

• Automatically inserted communications calls referencing CAPLib. Calls can then map toMPI, PVM, etc.

• Automatic generation of portable and scalable parallel code.

ParaWise is not a compiler. ParaWise has two distinct differences from a traditional paral-lelizing compiler.

The essential requirement for user interaction. This feature is essential for all stages of theparallelization process, including the dependence analysis, the inspection of loop types, the datapartitioning strategy and the communication and code generation.

The constraint on analysis time placed on a compiler as opposed to a parallelizing tool. To becommercially acceptable, a compiler must perform a parallelization in a fairly short time frame(typically minutes to an hour). However, a low quality analysis will greatly increase the requiredeffort to optimize the generated parallel code, whose quality has been directly diminished by thepoor analysis. In our experience a parallelization with a poor analysis is often disastrous withlittle the user can do to redeem the poor parallel performance that is invariably exhibited bythe generated code. The ParaWise dependence analysis can take a number of hours to performfor large codes or codes with complex control flow. However, the user time required to completethe parallelization is then not excessive.

The execution of the parallel code is not restricted to a fixed number of processors. Moreinformation can be found at the Parallel Software Products Inc. web site:

http://www.parallelsp.com/index.htm

C.3 PIPS and WPIPS

PIPS is an automatic parallelizer for scientific programs that takes as input Fortran 77 and HPFcodes. Since its inception in 1988, it emphasizes interprocedural techniques based on linearalgebra techniques.

PIPS is a highly modular framework which can be used to test and implement independentlyvarious compilation schemes, program analyses and transformations, such as automatic vector-ization and parallelization (Cray Fortran, CRAFT, CM Fortran, F90 & PVM output), HPFcompilation, loop transformations, partial evaluation,...

The compiler is made of independent phases that are called on demand to perform theanalyses or transformations required by the user. Consistency and inter-procedural interfaceissues are dealt with automatically.

The phase chaining is driven by an inter-procedural make system pipsmake and internal datastructures are automatically stored in a database pipsdbm which manages persistence throughdifferent runs. Persistence is used to avoid the memory bottleneck when large programs areanalyzed inter-procedurally. It is also used by newcomers to develop new applications withoutinterfering with existing code.

36

PIPS is built on top of two tools. The first one is data structure description language, NewGen,which manages allocation, de-allocation, storage for persistent objects, walks through complexdata structures, and provides basic classes, such as list, set and mapping. NewGen is embeddedin C, CommonLISP and SML. All PIPS data-types are declared with NewGen descriptions andused with the C or the Common LISP embedding.

The second tool is the Linear C3 library which handles linear formul and structures based onthese, such as vectors, constraints, polyhedra, generating system. This library is used to analyzecodes (preconditions, regions, dependence test) and to generate new versions of codes (partialevaluation, unimodular transformations, tiling, send/receive, temporary array allocation,...)

Three interfaces to PIPS are available: a shell interface (Pips), an X-Windows interface(wpips) and a hypertextual interface (epips).

More information can be found at:

http://www.cri.ensmp.fr/pips.

37

D The Polyhedron Software Ltd. mkkind Program

PROGRAM MKKIND

!

! Copyright (c) 1996 - Polyhedron Software Ltd. All rights reserved.

!

! This program writes the source code of a Fortran 90 module (normally

! called F77KINDS) which declares Fortran 90 kinds corresponding to some

! common but non-standard Fortran 77 types (such as INTEGER*2).

!

! When SPAG translates Fortran 77 to Fortran 90, it assumes that the

! module F77KINDS exists, and translates

!

! INTEGER*2 to INTEGER(I2KIND) etc.

!

! I2KIND is a PARAMETER in F77KINDS containing the KIND which

! corresponds to INTEGER*2.

!

! Because kind numbers vary between Fortran 90 implementations, the F77KINDS

! module has to be tailored to the compiler in use. To do this, simply

! compile and run MKKIND, using the target compiler, and it will produce a

! version of F77KINDS for that compiler. Using this scheme localises the

! system dependence to the F77KINDS module.

!

! Note that not all compilers accept all of the non-standard Fortran 77

! types, and you may have to modify this program to allow for that fact.

! For example, if LOGICAL*2 is not a supported type, you would have to

! comment out two lines, the declaration of L2, and the line that writes

! the parameter definition of L2KIND.

!

INTEGER*1 i1

INTEGER*2 i2

INTEGER*4 i4

LOGICAL*1 l1

LOGICAL*2 l2

LOGICAL*4 l4

REAL*4 r4

REAL*8 r8

DOUBLE PRECISION d

COMPLEX*8 c8

COMPLEX*16 c16

CHARACTER(8),PARAMETER :: FMT = ’(A,I2,A)’

OPEN(11,FILE=’F77KINDS.F90’)

WRITE(11,FMT) ’MODULE F77KINDS’

WRITE(11,FMT) ’!’

WRITE(11,FMT) ’! This module was generated automatically by MKKIND.F90’

WRITE(11,FMT) ’! (supplied with the plusFORT toolkit from Polyhedron &

&Software).’

WRITE(11,FMT) ’! It maps common non-standard Fortran 77 types to Fortran &

&90 kinds.’

WRITE(11,FMT) ’! Because different Fortran 90 compilers use different kind’

WRITE(11,FMT) ’! numbers, MKKIND.F90 should be compiled and run with the’

WRITE(11,FMT) ’! compiler you intend to use.’

WRITE(11,FMT) ’!’

WRITE(11,FMT) ’ INTEGER,PARAMETER :: &’

WRITE(11,FMT) ’ I1KIND =’ , KIND(i1) , ’, & ! INTEGER*1’

WRITE(11,FMT) ’ I2KIND =’ , KIND(i2) , ’, & ! INTEGER*2’

WRITE(11,FMT) ’ I4KIND =’ , KIND(i4) , ’, & ! INTEGER*4’

WRITE(11,FMT) ’ L1KIND =’ , KIND(l1) , ’, & ! LOGICAL*1’

38

WRITE(11,FMT) ’ L2KIND =’ , KIND(l2) , ’, & ! LOGICAL*2’

WRITE(11,FMT) ’ L4KIND =’ , KIND(l4) , ’, & ! LOGICAL*4’

WRITE(11,FMT) ’ R4KIND =’ , KIND(r4) , ’, & ! REAL*4’

WRITE(11,FMT) ’ R8KIND =’ , KIND(r8) , ’, & ! REAL*8’

WRITE(11,FMT) ’ DPKIND =’ , KIND(d) , ’, & ! DOUBLE PRECISION’

WRITE(11,FMT) ’ CX8KIND =’ , KIND(c8) , ’, & ! COMPLEX*8’

WRITE(11,FMT) ’ CX16KIND=’ , KIND(c16) , ’ ! COMPLEX*16’

WRITE(11,FMT) ’END MODULE F77KINDS’

CLOSE(11)

END PROGRAM MKKIND

39