From: molagnon@ifremer.fr (Michel Olagnon)
Newsgroups: comp.lang.fortran
Subject: (LONG) Re: NAG f90: any experience?
Date: 2 Oct 92 11:06:12 GMT
Reply-To: molagnon@ifremer.fr
Organization: Ifremer

In article 717165414@convex.rz.uni-duesseldorf.de, heisen@convex.rz.uni-duesseldorf.de (Henner Eisen) writes:
>   (.....)
>It would be very nice to use fortran 90. Since there are no native
>f90 compilers yet we are considering to buy the NAG f90 compiler.
>Thus, we are interested in anybody's experience.
>
>   (.....)

                  EXPERIENCE with NAG f90 COMPILER
                          Michel Olagnon
                          September 1992


INTRODUCTION

The intent of this document is to keep track of the experience gained by
FORTRAN 77 users when switching over to Fortran 90 (Nag compiler).
It was initiated when converting Fairie, a mixed C and FORTRAN application
of about 10 000 lines in each language, and is presently limited to use
on Sun workstations (Sos 4.1.2).
I hope to be able to develop it as new experience is gained, so please,
Dear Reader, do communicate yours.

As for anything that comes free, there is no garantee of correctness of 
what is expressed here, and we may laugh together in a few weeks of some
points where I stumbled over.

The following subjects are dealt with :
1. Source lay-out
2. System calls
3. Interfacing with C
4. Compile options
5. Strange behaviours
6. Performance
7. Debug
8. Conversion effort

Appendices, consisting of ftof90.c source, source of fft routines
used for performance tests and Makefile rules are freely available
from the author (Michel.Olagnon@ifremer.fr).

1. Any FORTRAN 77 code is legal Fortran 90
1.1 Strict, fixed form FORTRAN 77

The above saying is correct as far as code only is concerned, but problems
appear in the layout for :
- comments, which should start with ! in Fortran 90.
- continuation lines, which require the previous line to end with &.

In both cases, the former style raises problems.
A conversion utility, ftof90 has thus been written to replace FORTRAN 77
comments (character in column 1 amongst "cCxX*!", or blank line) with
Fortran 90 standard ones (character !, in this case in column 1).
It also appends & to column 73 of the line before a continuation line,
and substitutes the character in column 6 with &, redundant but accepted
by the Fortran 90 standard [1].

The output of ftof90 remains compatible with versions 1.3 or 1.4 of the
f77 Sun compiler, and respect, of course, the fixed form code style of 
FORTRAN, which I suggest should be adhered to until FORTRAN 77 disappears.

Usage hints for ftof90 :
ftof90 [-v] file.f [file2.f ... filen.f] [> file.f90]
-v prints on stderr all modified lines.
When several file names are given, they are concatenated on output.
When no file name is given, the program reads stdin.
To convert (keeping suffix .f) all files of directory ../f77 into
files in the current directory, type :
ftof90 ../f77/*.f | fsplit

1.2 Unsupported former laxism

Spaces appearing within constants or operators are no longer supported, for 
instance :
1.0 d0
EQ .
0. 1234

Intrinsic functions should generally be referenced by their generic names.
Specific names, such as DCOS instead of COS, are accepted if used
correctly, FLOAT and DFLOAT, which did not belong to the FORTRAN 77
standard, are rejected (use REAL and DBLE).

2. Where are the system calls ?

Since the Nag compiler uses the same function naming convention as the former
f77 (trailing underscore), and the same argument passing scheme, system calls
such as GETENV or IEEE_HANDLER can still be used, as long as the
right libraries are specified at link time.
The only exception is GETARG (see further, interfacing with C).

Libraries to be used are :
- for Fortran 90 : -L/usr/local/lib/f90 -lf90
- for FORTRAN 77 system calls : -L/usr/lang/SC1.0.1 -lF77
- for C calls : -lm -lc

3. Can I mix my own C with f90's ?
3.1 C subroutines

Since the Nag compiler uses the same function naming convention as the former
f77 (trailing underscore), and the same argument passing scheme, calls to C 
routines that worked previously still do.

3.2 C main

Calling f90 subroutines from a C main program does not work straightforwardly,
because f90 provides its own main in the libf90.a library, and one thus gets
complains about double defs.
A workaround is to have the f90 main call your C main as it would have called
a f90 main, after it has performed some initializations.
It should then be called f90_main (). It is NOT possible to access
command line arguments.

3.3 Command line arguments

The Nag compiler gives no means to access command line arguments.
Of course, there is no mention in the standard of interfacing with the system,
yet one can regret that a GETARG function, or its equivalent, is not
provided.
I suggest to use environment variables, accessed via GETENV, as a
workaround.

4. Are compiler options compatible between cc, f77 and f90 ?

Some of the compiler options, common to cc and f77, are not accepted by f90,
for instance, -pipe -libmil -cg89.
It would have been pleasant that Nag would have enabled transmission of such
options to the C compiler parts that they call by some environment variable,
say CFLAGS.

Of course, f90 can be made to generate C code (option -S), which may in turn
be compiled with any C option (and -I/usr/local/lib/f90), but this does
not seem very efficient.

Note also that option -o is passed to the loader, so for instance,
 f90 -c file.f90 -o /tmp/file.o ends up with file.o in the current
directory, not in /tmp.

5. How to get rid of the funny messages

At the end of execution, some messages about floating point exception handling
appear :
Note: Following IEEE floating-point traps enabled; see ieee_handler(3M): 
 Overflow;  Division by Zero;  Invalid Operand; 
 Sun's implementation of IEEE arithmetic is discussed in 
 the Numerical Computation Guide.
Note that it does not say that any exception indeed occurred. Though the
Numerical Computation Guide is indeed recommended reading, you may want to get
rid of the message. Use CALL EXIT then to terminate execution.

A less funny message was when a program failed silently on my SS1+, so I
tried it on the 690 MP server, ... and crashed the server.
Now that Fortran supports pointers, beware of them !

6. Is f90 90% slower ?
6.1 Compilation

Based on compilation times for a 866 instructions file, it appears that
f90 takes 50% more to compile without optimization than f77 v1.4.1.
Optimization increases time only by 200% for f90, and by 500% for f77, 
but may not be as thorough.
On our Sun 690 MP :
f90 --> 7.2 s,   -O --> 19.2 s
f77 --> 4.9 s,   -O --> 26.2 s

6.2 Execution

Fortran 90 is meant to make full use of features such as vector instructions,
parallelism, etc... which are not available on our Sun, nor from the Nag f90
compiler.
Execution results may thus seem disappointing. I have tested speed on a program
operating 100 times a Fast Fourier Transform and its inverse on an array of
8192 values (Gumbel distributed, between 1. and 3.).

The following results were obtained with a Sun 690 MP :
Fortran 77 v1.4.1, -O optimization : 40.0 s.
Fortran 90, same source code, -O :   61.0 s.
Fortran 90, rewritten code, -O :    278.0 s.
The rewritten code was inspired by legibility and my understanding of the 
"Fortran 90 spirit", not performance. Yet I do feel disappointed, and suggest
that use of array features instead of loops be limited to strict necessity.

7. Can I still use the debugger ?

In my humble opinion, use of the debugger should be restricted to cases when
one is not able to write correct code from the beginning (which means that
(s)he had better go and write poetry ...), but when I had to use it, I
verified that it still worked, provided one does not forget to append trailing
underscores to variable names and that main program is named "f90_main",
and ignoring some warning messages that main is not compiled with -g option
and that temporary C files are gone.

8. How long does it take to switch over ?

There are more than 10 000 lines of Fortran, and about as many of C, in the 
Fairie application (a user-interface and libraries for development of
scientific applications).
A working f90 version has been realized in 1 1/2 day, though only obsolescent
features and compile errors led to upgrade.
Most of that time was spent writing ftof90 and Makefiles,
compiling, managing the 500 different routines and finding workarounds for
non-standard parts such as command line arguments, NaNs, etc...

Performance tests and writing this document (1 more day) represent more 
truly switching over. It is not difficult, it is just extending FORTRAN 77
code, making it clearer and more legible, simpler, and puting into it what
you had always felt was missing.

Concluding remarks

Malcom Cohen did a wonderful job in writing this compiler.
It works, reasonably fast, and enables to use Fortran 90 today.

We have felt that an application needing rewriting (synthetic seismograms
computation, formerly running on a Cray 1 and now on our Suns) should be
rewritten using this compiler, and work already started.

Of course, we now long for "production compilers", but Fortran is alive
again, and scientists will use it.

References

[1] ISO/IEC 1539
Standard programming language Fortran.
[2] METCALF, M. and REID, J.
Fortran 90 Explained, Oxford University Press, 1990.

---
| Michel OLAGNON            | email : Michel.Olagnon@ifremer.fr  |
| IFREMER - Centre de Brest | member of Nag Users Association    |
Newsgroups: comp.lang.fortran