A Leonard writes:
> Can you give me compelling reasons to use to convince our management and the
> other developers here to take the time to convert more than 200,000 lines of
> existing code to Fortran 90?
It should not take any time at all to convert Fortran 77 code to
Fortran 90. Fortran 77 is a subset of Fortran 90, so all Fortran 77
code is already Fortran 90 code.
Now if your existing "Fortran 77" code isn't really Fortran 77, but is
instead full of vendor extensions, then that might be a different
matter. You did mention porting to various platforms, so I'd guess
that you probably don't have too extreme a case of dependence on
uncommon vendor extensions.
It may be that you are talking about using some of the new features
of Fortran 90. That is a bit of a different issue than converting
to Fortran 90. One of the differences is that it is possible to
introduce new features gradually and only in places where they prove
helpful. You aren't forced to do everything all at once. Of course,
I've seen cases where it proved worthwhile to tear a program
completely apart and redo it from scratch, but those things vary
widely.
The redo-from-scratch cases that I most recall were in programs where
the whole program structure was driven by memory management issues
from days with smaller computers and with the memory management done
by the program. Throwing the old stuff out and recoding ended up
with something about 1/4 the lines of code - and the recoding probably
took less time than porting the old stuff would have done). Such
situations do happen, but not to everyone.
> The main advantage I see is memory allocation. Next would be elimination of
> include files and common blocks in favor of modules.
Those are good things. And they can be introduced gradually. It is
possible to use modules for some things, while still using COMMON
for others. Its even possible to put a COMMON block in a module -
that often works out nicely as a transitional stage.
Another good thing is the improved error checking you get with such
things as explicit interfaces.
And there are a whole bunch of things that you may already be using
and calling f77, even though they are not standard f77 (but are
standard f90). Variable names longer than 6 characters, implicit
none, DO/ENDDO, "!" for comments, etc.
The combination of free source form (with significant blanks) and
implicit none can help kill a lot of bugs.
> It is my impression, from a previous job, that Fortran 90 compilers
> are not all as mature as they should be.
I don't think that's a very accurate portrayal any more. I'd say
more that f77 compilers are (slowly) disappearing from the marketplace.
There are quite a few vendors that no longer offer f77 compilers
as separate products, but instead use their f90 compilers for
both f90 and f77 code (see first paras of my reply). IBM has done
this for a long time. I see that HP is dropping their f77. Etc.
You mentioned doing development on PCs. (I'm assuming on MS windows,
since thats what people that don't say usually mean; if you meant
Linux or one of the other choices, you'd have probably said). Most of
the current PC compilers are f90 (or f95). If you insist that it's not
allowed for your compiler to support f90, then there are some options,
but that's going to limit you quite a bit. Any more, I'd worry more
about the continuing support of the f77 compilers than the maturity of
the f90/f95 ones.
F90 is almost a decade old now - scarcely new and untried.
"As they should be" is hard to define. Improvements are always
possible and often desired.
Optimization of whole-array operations is certainly an area that could
use a lot of improvement. I recommend against wholesale conversion of
everything to use whole array syntax. In some places, whole array
syntax greatly helps clarity, and in some places it might help
performance. In other places, it could hurt. There have been a lot
of people who seem to think that DO loops aren't allowed in f90,
or anyway that they are bad style. Thus, we hear a lot of comparisons
described as f77 vs f90 comparisons that turn out to really be all
about DO loops vs whole array syntax. Don't make that mistake.
Use whole array syntax when it helps clarity. Where performance
is a major issue, test instead of assuming - there can be great
surprises, and it can vary from vendor to vendor.
--
Richard Maine
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|