Changes Fortran 77 -> Fortran 90/95/X?

[h-faber]

Hi,

in my customer project I made old Fortran 77 code run with some new Fortran 90/95 code (GETARG etc.) with the IVF 8.1.

My question now is:

Is it senseful, if so, why, to fully convert all the Fortran 77 code to Fortran 90/95 or even higher?

Is Fortran 90/95 the newest Fortran or is there some newer Fortran available, also integrated in IVF 8.1?

If this is senseful, where can I find all the changes from Fortran 77 -> Fortran 90/95/X? I know of some changes concerning the comment symbol and .GE. replaced by >= etc. but does therea complete table, list or something like that exist? If so, where can I find it?

Thanks in advance,

Harald

[Jugoslav_Dujic]

First, let me clarify: there is (almost) no changes from F77 to F9x. All that F9x brought were additions and extensions. Thus, your "F77" code is in the same time a valid F9x code and you can legitimatelysay "My codeis F95 compliant".

That being said, there are many advantagesin new features ofF9x that you may want (or not) to use. In my opinion, people generally accept some F9x features they find more practical first, and reject some, making the shift gradually. This is only matter of practical issues and personal preferences. For example, I still prefer .GE. and .LT. to >= and < -- it's just a matter of habit.

For example, if you don't intend to much maintain/develop that code further, you can leave it as-is, on the principle "don't fix if ain't broken". If you do intend to spend much time improving it, you may consider some of the following changes, which I find most appealing in the "porting":

1) change the fixed-form source to free-form source. That can be automatized by some of free utilities, like one from Alan Miller

2) replace COMMON blocks by module variables.

2a) make the arrays allocatable in order to allow for free sizing of the problem

3) use IMPLICIT NONE to force variable declaring and prevent stupid mistyping errors difficult to track

4) replace "old style" blocks (like IF(x) GOTOor DO260 i=1,...) with structured blocks (IF...ELSE...ENDIF, DO...CYCLE..END DO)

5) use array notation

6)use new intrinsic routines tomake the code more elegant and readable

7)...

It's up to you which changes you will find useful and which not. Generally, they all lead to better code readability and easier maintenance (and performance gains are unlikely).

Hope this helps

Jugoslav

[TimP]

ifort doesn't yet incorporate much of Fortran 2003, beyond what is in the f95 standard. A few f95 intrinsics could give better performance as well as readability than equivalent f77 code:
MATMUL (when BLAS call is not suitable),MERGE (more so in ifort 9), MAXLOC/MINLOC

[h-faber]

---

JugoslavDujic wrote:

First, let me clarify: there is (almost) no changes from F77 to F9x. All that F9x brought were additions and extensions. Thus, your "F77" code is in the same time a valid F9x code and you can legitimatelysay "My codeis F95 compliant".

That being said, there are many advantagesin new features ofF9x that you may want (or not) to use. In my opinion, people generally accept some F9x features they find more practical first, and reject some, making the shift gradually. This is only matter of practical issues and personal preferences. For example, I still prefer .GE. and .LT. to >= and < -- it's just a matter of habit.

For example, if you don't intend to much maintain/develop that code further, you can leave it as-is, on the principle "don't fix if ain't broken". If you do intend to spend much time improving it, you may consider some of the following changes, which I find most appealing in the "porting":

1) change the fixed-form source to free-form source. That can be automatized by some of free utilities, like one from Alan Miller

2) replace COMMON blocks by module variables.

2a) make the arrays allocatable in order to allow for free sizing of the problem

3) use IMPLICIT NONE to force variable declaring and prevent stupid mistyping errors difficult to track

4) replace "old style" blocks (like IF(x) GOTOor DO260 i=1,...) with structured blocks (IF...ELSE...ENDIF, DO...CYCLE..END DO)

5) use array notation

6)use new intrinsic routines tomake the code more elegant and readable

7)...

It's up to you which changes you will find useful and which not. Generally, they all lead to better code readability and easier maintenance (and performance gains are unlikely).

Hope this helps

Jugoslav

---

Hi Jugoslav,

thanks for this detailed answer. What I have to evaluate is:How much time do I have to spend and what do I have exactly to do to change the existing Fortran 77 code to a clean and pure Fortran 95 code to be safe in code for the next x years? Which are the reasonablepros to do this "conversion" to Frotran 95 now? Remember that I have reached a state where the old VAX/VMS Fortran 77 programs now run with IVF 8.1. I have to argue why it is senseful to change the (working) F 77 programs into F 95 programs. Are there reasons and risks for/against this step?

Maybe I am wrong but my understanding is that e.g. .GE. is Fortran 77 while >= is "real" Fortran 95. I still might use .GE. but thenative Fortran 95 usage is >=. So if one day Intel compilers only understand pure Fortran 95, I have to switch to >= etc.

Like:

Fortran 95: >= / Fortran 77: .GE.

Is this right?

Or is it:

Fortran 95: >= and .GE. (I choose)

?

On http://www.nsc.liu.se/~boein/f77to90/c1.htmlI have read:

"It is possible to mix old and new statements, but it is advised to try to be consistent, which means using either the old or the new form for the statement."

Is there some kind of table or list available old statements vs. new statements?

Message Edited by h-faber on 06-09-2005 01:51 AM

[h-faber]

---

tim18 wrote:
ifort doesn't yet incorporate much of Fortran 2003, beyond what is in the f95 standard. A few f95 intrinsics could give better performance as well as readability than equivalent f77 code:
MATMUL (when BLAS call is not suitable),MERGE (more so in ifort 9), MAXLOC/MINLOC

---

Hi Tim,

thanks for this answer too, although I have to admit that I have never seen those words in the old F77 code nor do I (yet) know what they are good for and what they can replace in the old code. ;)

[Steven_L_Intel1]

You do not have to change anything. Your F77 code will continue to be supported, at least by Intel compilers, for many years to come. It is the general opinion of Fortran compiler vendors that they can NEVER completely remove old language syntax, as customers are still building F66 programs. The compilers do, of course, have the ability to warn you that you used a feature no longer in the current standard, but your code will continue to compile and work.

If you write new code, feel free to take advantage of new language features, but my own opinion is that it is not a good idea to rewrite working code just to bring it into line with the current standard.

Now, if you feel that the old code is unmaintainable (in that it is so full of convoluted GOTOs, etc., that nobody can understand it), you can consider rewrites. But otherwise, leave it alone and put your energy into something new.

[h-faber]

Hi Steve,

thanks for pointing this out. I guess it would be a hard and time spending task to change all the common-blocks etc.

[Steven_L_Intel1]

Common blocks? Those are still in the current standard, and I know of no plan to remove them.

Do a compile with /stand:f95 and see what the compiler says.