VX/FPT
Overview
VX/FPT (FORTRAN Partner) is a powerful suite of tools for writing, maintaining and migrating FORTRAN programs. Many of the world's leading aerospace and high technology companies use it.
Features
| The Major Features of VX/FPT | |
| Feature | Description |
| Quality Assurance | VX/FPT detects errors not normally detected by compilers and linkers. It can guarantee that code is free of many classes of error. |
| Error Correction | VX/FPT can correct some errors automatically, and document the changes it has made. |
| Standardization | VX/FPT reformats code to a user's chosen style. It can insert declarations and re-program control constructs to conform to a house standard. |
| Migration/Porting | VX/FPT can make systematic changes to port code between hosts. It can automatically convert constructs from VMS, from Gould-SEL and from many other systems to standard FORTRAN. |
| Software Engineering | VX/FPT can automatically generate an interactive and command file control system for a program. It can instrument code to automate regression testing. |
| Optimization | VX/FPT can expand sub-programs in-line and unwind loops to optimize code to speed execution. |
| Report Generation | Reports for program documentation include the symbol table collated across all sub-programs, COMMON block listings in address order, and the program call tree. |
| User Interfaces | VX/FPT troubleshoots and debugs code interactively or runs in batch mode as part of a QA or build procedure. |
| Security | If required, VX/FPT can protect source code by making it unintelligible, while preserving its integrity as compilable FORTRAN. |
| Hosts Supported | The supported hosts include VMS, DEC Unix, HP-UX, AIX, Irix and Solaris. |
| Documentation | The documentation is available on-line in Adobe Acrobat 4 format. The Tutorial Guide provides an introduction for the user's first use of FPT on his or her own programs. The Reference Manual contains the installation procedures, and a detailed description of all VX/FPT commands. The User's Guide describes how VX/FPT may be used to achieve specific objectives, such as QA auditing and migration of code between platforms. |
Quality Assurance
FORTRAN programs are used to design aircraft, ships, bridges, power plant, space craft... The engineers already know that the results they generate are about right. Man years of program development on expensive equipment are invested for the last few percent of accuracy which go beyond the engineer's intuition.
Those last few percent depend on the quality of the code. But in 100,000 lines how can we know that all of the subroutine arguments are consistent, that none of the statements run into the comment field beyond column 72; that there are no commas missing from lists? Compilers and linkers are unlikely to find these problems. Imagine the labour of checking 5000 subroutine call sites visually to see whether the arguments are consistent with the sub-program definitions. These checks are automated by VX/FPT.
The example below came from a real simulation program:
C Reduced climb for payload
LOAD=(RAN(IRAN) .GT. 0.5)
IF(LOAD)THEN CLIMB=CLIMB-MLOAD
!----------------^-----------------------------------------------------
!!! VX/FPT - THEN may not be used to introduce a sub-statement in FORTRAN
!----------------------------------------------------------------------
C
C Position of military aircraft
X1=DELAY*SPEED1*SIND(BEAR1)
|
The keyword 'THEN' has been used incorrectly. A FORTRAN compiler creates a new variable called 'THENCLIMB' to receive the value of 'CLIMB-MLOAD'. 'THENCLIMB' is not referenced elsewhere in the program and the result is thrown away!
The Q.A. checks made by VX/FPT include the detection of:
- FORTRAN keywords and intrinsic function names apparently used for variables and arrays
- Text running into the comment field at the end of the FORTRAN line
- Space characters embedded in names or numbers
- Variables which are read but never written, written but never read or declared but never used. The check is made across all sub-programs, taking into account the way different routines access COMMON blocks
- Subroutine and function arguments of the wrong data type or size (e.g. REAL*8 for REAL*4)
- Named COMMON block locations with different types or addresses in different sub-programs
- Different objects which occupy the same memory in COMMON blocks
- FORTRAN parameters with different values in different sub-programs
- Variables in COMMON blocks, STRUCTURE constructs or EQUIVALENCE statements, which are not aligned to the appropriate byte boundaries in memory
These checks can be configured by the user, and are made with surprising speed, even for large applications. They may be made either interactively or in batch mode.
One user summarized the power of FORTRAN Partner™ by saying:
- "...we needed a black box that could look at code before our developers spent
£20,000 on a day's use of the simulator. VX/FPT paid for itself on just
one day! "
Error Correction
VX/FPT identifies errors and inconsistencies in FORTRAN codes (Please see Quality Assurance ). It may be used to correct some classes of error automatically. The most important corrections are to sub-program arguments. Consider the function call:
ALPHA = ACOS ( BOUND ( 0, HDOT / V, 1 ) ) |
The function BOUND is a limiter, which is used to keep the input to ACOS within the range zero to one. It is coded as:
FUNCTION BOUND( LOW, INPUT, HIGH )
REAL LOW,INPUT,HIGH
BOUND = MIN ( HIGH, MAX ( LOW, INPUT ) )
RETURN
END
|
The problem is that all three arguments to BOUND should be real, but BOUND has been called with the arguments integer 0, real HDOT/V and integer 1. The integer value of zero is unlikely to cause a problem. Most systems treat integer zero as equivalent to real zero. The integer 1 will usually cause an error.
The VX/FPT command to correct problems like this is " Correct inconsistent arguments ". VX/FPT checks all arguments in the entire program. Corrections are made by re-writing the arguments or by inserting calls to intrinsic functions (e.g. REAL(), DBLE(), INT() etc.). Inconsistent arguments which cannot be corrected are marked by diagnostics.
The call above is re-written as:
ALPHA = ACOS ( BOUND ( 0.0, HDOT / V, 1.0 ) ) !------------------------------^--------------^-------------------------------- !!! VX/FPT - 1873 Actual argument has been changed to match formal argument. !!! VX/FPT - 1873 Actual argument has been changed to match formal argument. !------------------------------------------------------------------------------ |
A large FORTRAN program has many authors and a lifetime of many years. Code is inherited from other projects. Differences in style, in management and in the available programming tools lead to the creation of a dusty deck. The indentations may no longer represent the control structures; to find all the assignments of 'THETA' you may need to search for
|
'THETA =', 'Theta=', 'theta=' ... |
VX/FPT makes maintenance of such code manageable.
VX/FPT automatically reformats source code to a consistent set of standards requested by the user. It deals with indentations, adds or removes spaces before and after tokens, checks line lengths, allows specifications of upper or lower case keywords and variables. It changes the format of real numbers, handles continuation lines, deals with the renumbering of statement labels and with many other issues to make life easier for the FORTRAN programmer. It also contains a language sensitive editor which allows FORTRAN identifiers to be renamed systematically. Each user works in his or her own coding style, and the code is reformatted to a company standard before release.
The same reformatting features may also be used to make code unmaintainable - to protect source code by removing the comments and encrypting the variable names, making it unintelligible to others. This has proved useful in situations where sensitive code is handed over to third parties in a compilable form (Please see Security ).
A four year old workstation is obsolete. Scientific and engineering FORTRAN codes live for decades. One of the most powerful attributes of VX/FPT is that it enables users to port their software from one computer system to another.
| A VX/FPT migration typically has four steps: | |
| Step | Description |
| Checking the Code | VX/FPT checks for errors in the original code. It is much easier to migrate correct code than code which contains errors. If the code doesn't run correctly on the new host, we need to know that this is because of the migration process, not because of an existing bug which has shown its symptoms in a new way. See Quality Assurance for a description of the checks. Any errors are corrected on the original host before migrating the code. |
| Preparing Tests | The Record/Replay (Hamlet) facility captures test data on the original host. A common problem is that packages are made up of groups of programs which interact through file I/O, network I/O or shared memory. VX/FPT captures data from the interfaces so that the programs may be tested separately. |
| Converting the Code |
VX/FPT converts many language extensions to standard code in a single pass, in very much less time than the FORTRAN compilation. The changes are repeatable. Usually they are controlled by a script which is adapted to produce the desired result. We avoid the situation where the source is modified manually through intermediate stages where it won't run on either host. The changes depend on the characteristics of the hosts. VX/FPT has extensive facilities for migration:
|
Testing and Debugging |
The migration is tested by replaying the recorded data. The replay mechanism allows the real interfaces to be added progressively. Difficult debugging issues can be attacked by the VX/FPT run-time trace facility - VX/FPT instruments sections of the code to capture every left-hand-side scalar quantity to file, and it is then possible to find the point at which two program runs diverge. Data sets may be compared by the RDIFF utility, a file comparator which is insensitive to real number formats and to small differences between numbers. |
Optimization
VX/FPT carries out in-line expansion of subroutines and functions, and unwinds DO loops, to optimise code for speed of execution. The effects of the optimisations depend on the host architecture. There are trade-offs between processor speed, memory speed and instruction cache size. Run times are typically improved by 20% to 40%, and by as much as a factor of two or more on high performance processors inhibited by memory speed.
Sub-program calls may interfere seriously with compiler optimisations. For example:
R=R0+ALPH(I1,I2,I3,CELL)
FR=INTERP1(TYRESPEED,TYREVBP,TYREFRICT)
ALPH(I1,I2,I3,CELL)=FR*T0
|
In this example 'ALPH' is an array and the indices, 'I1', 'I2', 'I3' and 'CELL' are variables in a COMMON block. The compiler must generate code to re compute the indexed address within 'ALPH' in case the COMMON block variables are modified during the call to the function 'INTERP1'. When 'INTERP1' is expanded in-line the memory address of the array element can be saved in a register for re use.
VX/FPT comments the changes that it makes in the expanded code, so that it remains readable for debugging. The linear interpolation function, 'INTERP1' called in the example above is:
REAL*4 FUNCTION INTERP1(INPUT,BP,FUNTAB)
REAL*4 INPUT
REAL*4 BP(*)
REAL*4 FUNTAB(*)
I=1
DO WHILE (BP(I) .LT. INPUT)
I=I+1
ENDDO
INTERP1=FUNTAB(I-1)+(FUNTAB(I)-FUNTAB(I-1))*
1 (INPUT-BP(I-1))/(BP(I)-BP(I-1))
RETURN
END
|
VX/FPT expands the call to read:
R=R0+ALPH(I1,I2,I3,CELL)
C ****************************************************************************
C
C FR=INTERP1(TYRESPEED,TYREVBP,TYREFRICT)
C
I=1
DO WHILE (TYREVBP(I) .LT. TYRESPEED)
I=I+1
ENDDO
INTERP1_VAL=TYREFRICT(I-1)+(TYREFRICT(I)-TYREFRICT(I-1))*
1 (TYRESPEED-TYREVBP(I-1))/(TYREVBP(I)-TYREVBP(I-1))
C RETURN INTERP1
C
FR=INTERP1_VAL
C
C ****************************************************************************
ALPH(I1,I2,I3,CELL)=FR*T0
|
Note that the modified code is marked by bars across the text, and the original statement, the assignment of 'FR', remains in place but is commented-out. The formal arguments in the function have been replaced by the actual arguments to the call.
In this example, there was no variable named 'I' in the scope of the expanded statement, so the name of the variable 'I' in the function was retained. Variables are renamed if name clashes occur. Declarations of variables used in the expansion are inserted in the routines which require them, and they are moved to COMMON blocks if they have a SAVE attribute or are SAVEd by default.
In-line expansion may be carried out quickly and easily, and it is recommended that users maintain code in unexpanded form. VX/FPT may therefore be used to resolve a common conflict in the maintenance of large programs. It is good practice to encapsulate small, frequently used operations, such as accesses to data structures, in subroutines or functions. Maintenance changes are then made in only one place. However, a large number of sub-program calls slow down program execution.
With VX/FPT, users may choose to encapsulate primitive operations and to expand the calls in-line before the release of production code.
In-line expansion and loop unwinding are controlled by the VX/FPT commands Expand inline and Unwind marked loops. The commands Inline and Unwind are written in the code to mark candidate routines and loops for expansion.
Hosts Supported
The supported hosts include Linux, VMS, DEC Unix, HP-UX, AIX, IRIX and Solaris.
- Linux
- DEC VMS and OpenVMS VAX
- DEC OpenVMS AXP (Alpha)
- DEC Unix (Alpha)
- IRIX
- HP-UX
- AIX
- Silicon Graphics
- SUN SPARC (SunOS and Solaris)
- FORTRAN support for the Applied Dynamics International AD100
This list is continually being updated, so please contact Sector7 for the latest details.



