Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Should I change my obsolete fixed form code to free form?

jirina
New Contributor I
1,261 Views

I inherited a complex application that is written in the fixed form. It has about 100 000 lines of code (without comments) based on what cloc.exe I found on Internet calculated.

My question is - as the fixed form is obsolete, should I consider changing it to free form? If this is recommended, is there any tool.that could make this process at least partly automatic?

0 Kudos
17 Replies
TimP
Honored Contributor III
1,261 Views

If you try this, I suggest trying at least one of the commonly used open source or commercially supported translators.

Speaking for myself, I have made the free format conversion for a few projects and not for others.  The commercial plusfort translator includes assistance in updating syntax, which I consider more important than the format change.

Historically, one way to tackle this was to translate to ratfor  (a Fortran 66 compatible structuring preprocessor) and improve the translators so as to end up with a more useful g77 compatible source code.

I've found it necessary to split source into individual procedures and test the conversion incrementally.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,261 Views

>>I've found it necessary to split source into individual procedures and test the conversion incrementally

Strongly agree.

The following steps may be helpful

1) Assure all procedures (functions and subroutines) have IMPLICIT NONE. This may be a lot of work, but well worth the effort. In the process this may expose variable names that cross the 72'nd character boundary. If so, then you will have to determine the correct fix (may not be clear as to what is correct).

2) Make a test build with the IVF interface checking enabled. Shake out any errors (procedure at a time with tests of results as you go).

3) now do the procedure by procedure "conversion". This may simply be as easy as changing the file type to .f90, but you may have some clinkers with the continuation lines (non-blank in column 6). Verify results as you progress

4) convert COMMONs into module storage. *** this is not trivial when the named common blocks map the differently ***

Jim Dempsey

0 Kudos
Steven_L_Intel1
Employee
1,261 Views

My philosophy on such things is: "If it ain't broke, don't fix it". I am sure your code has other obsolete or even deleted usages in it, if it is old. Sure, if you're developing new sources there's no excuse to not use free-form, but "converting" existing source is a waste of time (and probably will introduce bugs). It will also likely make the code harder to read.

I would focus instead on things Jim recommended in #3 - use the available tools to make the existing code more robust. Fixed form will continue to be supported by any compiler you are likely to use.

0 Kudos
LRaim
New Contributor I
1,261 Views

I completely agree with Steve about this subject.

In addition I don't understand the suggestion of changing COMMON into storage modules.

They are different things. For example you can dump or write a COMMON structure very easily but the same thing is quite impossible with storage modules.

0 Kudos
NotThatItMatters
Beginner
1,261 Views

My experience with this is the following: conversion to free form should only be considered if you need to further develop or extend the code.  In the examples I have worked this was important.  It was not only a question of code maintenance, it was code extension.  When you are faced with a computed GOTO construct which obviously translates into a SELECT CASE construct, the conversion is more or less straightforward to change it and then add whatever new CASE statements are needed to extend it.  The more difficult conversions to de-spaghettify may be the simpler constructs, such as DO WHILE or IF ELSE IF END IF.

My call is to convert those things that require development and leave the remainder as is.

0 Kudos
Scott_L_
New Contributor I
1,261 Views

 

I have found it awkward to move back and forth between reading fixed and free form.  So I would prefer to convert all the source code to free for consistency.   the fortran marketplace has a converter I was able to get working well enough.

 

scott

 

0 Kudos
TimP
Honored Contributor III
1,261 Views

NotThatItMatters wrote:

  When you are faced with a computed GOTO construct which obviously translates into a SELECT CASE construct, the conversion is more or less straightforward to change it and then add whatever new CASE statements are needed to extend it.  The more difficult conversions to de-spaghettify may be the simpler constructs, such as DO WHILE or IF ELSE IF END IF.

 

I converted legacy benchmarks from computed goto to select case, as I hoped for a more interesting performance comparison among compilers and languages. 

A customer determined that computed goto still gives sufficiently better performance, without dependence on workload dependent profile guided optimization, that he didn't want to change his application.

I'd be surprised if code which used do while or if else if in any reasonable way, other than in conjunction with goto, would need restructuring.  For the case where they are mixed with goto, I have a flex script to turn the whole thing into f66 so as to restructure it all together.

In my webinar this morning, I showed a case where if..else... might be replaced by multiple merge intrinsics, with considerable gain in performance but at the cost of cryptic appearance.  I wouldn't have classified it in this category.

0 Kudos
rase
New Contributor I
1,261 Views

I use a lot of legacy code. I agree that it is not always worthwhile to change from fixed to free format, and keep the fixed format. I am a strong supporter of "If it ain't broke, don't fix it". But if the legacy code contains lots of GOTO constructs and other F66 oder F77 elements it is better to use a formating tool such als plusfort to convert the sources to a more recent dialect of Fortran, especially in respect to maintainability. DO loops, SELECT CASE and IF clauses with adequate indentation are much easier to decipher than old sphagetti code. By using plusfort it is possible to export the code in fixed or free format, whatever is more convenient, or change or unify the case for specific keywords and variable names. A formatter can also resolve the problem that inserting IMPLICIT NONE causes a lot of manual editing and testing.

0 Kudos
jirina
New Contributor I
1,261 Views

I would like to thank everybody for sharing their experience and opinions.

Let me add to my original post that the code I have is about 10 years old and the first thing I did was that I got rid of all GOTOs. I am both maintaining and extending the code, so I started using modules instead of COMMONs, which I did only for new parts of the code. Also, I enabled in options that one line can be up to 132 characters (I use up to about 100).

My biggest concern was that the fixed form is considered obsolete and it could happen that it would not be supported. Based on what Steve Lionel stated in his post, the fixed form is going to be supported in forseeable future.

0 Kudos
TimP
Honored Contributor III
1,261 Views

If I understood Steve's comments elsewhere, he prefers free form over fixed form with increased line length options.  Among the problems with the non-portable increased fixed line length options is that it's not possible (to my knowledge) to set up INCLUDE files so as to work with multiple fixed format line lengths and also with free form.

0 Kudos
NotThatItMatters
Beginner
1,261 Views

The only problem in INCLUDE files between fixed and free form is the line continuation characters, and recalling from something I did in this behalf ten + years ago, you put the line continuation & in column 73 and also on the next line put an & in column 6.  This allows the include file use by both fixed and free-form code.

My code was fixed form until I got here, and all development and file update has been free form.  I still have a dozen or two fixed form source files, but that too at some point will be updated.

0 Kudos
TimP
Honored Contributor III
1,261 Views

NotThatItMatters wrote:

The only problem in INCLUDE files between fixed and free form is the line continuation characters, and recalling from something I did in this behalf ten + years ago, you put the line continuation & in column 73 and also on the next line put an & in column 6.  This allows the include file use by both fixed and free-form code.

That's correct.  The point is that the longer line length fixed format options will fail with the & in column 73, besides exhibiting other possible minor differences among compiler vendors.

0 Kudos
FortranFan
Honored Contributor II
1,261 Views

jirina wrote:

.. Let me add to my original post that the code I have is about 10 years old and the first thing I did was that I got rid of all GOTOs. I am both maintaining and extending the code, so I started using modules instead of COMMONs, which I did only for new parts of the code. Also, I enabled in options that one line can be up to 132 characters (I use up to about 100). ..

Out of curiosity, when you are using Fortran 90 (and perhaps other features from later standards), why would you use fixed-form source only to turn on some non-standard options such as the one for longer lines?

As you would know well, you can indeed have free-form source files with all standard features but with your own coding styles (which may be informed by the older fixed-form idioms).

0 Kudos
jirina
New Contributor I
1,261 Views

I indeed started using some Fortran 90 features to extend the existing code, and my plan from more than 5 years ago was to update the whole code to free form and to get rid of obsolete features; however, I have never had time to do that. I am still considering to do so, which I suppose will require dealing with continuation lines.

0 Kudos
bmchenry
New Contributor II
1,261 Views

From the many thousands of lines and thousands of subroutines i converted from Fortran IV and older to the modern age i would suggest you consider PlusFort from Polyhedron

Has so many dials on the set you'll have fun deciding what you want to do in the conversion process.

It has a cost however in the hours i saved with it i expect you will find it well worth the investment (and they do have academic discounts)

brian

and i have no association in any way with Polyhedron, just have found it to be a great way to clean up and modernize old code.

There used to be another company Cobalt-Blue which had FOR_STRUCT and FOR_STUDY which i also used many years ago however they i believe no longer market their software.
 

0 Kudos
TimP
Honored Contributor III
1,261 Views

bmchenry wrote:

There used to be another company Cobalt-Blue which had FOR_STRUCT and FOR_STUDY which i also used many years ago however they i believe no longer market their software.

 

As the Unix V7 F66 to ratfor structuring translator was named struct, it seemed likely to have been a strong influence in that product.  The source code for it was included in the Unix source, so we were able to spend some time debugging it and making it more compatible with standard C.  Without too much modification, it can be built with current linux and cygwin tools.  I suppose it may have been in Unix v6.

0 Kudos
rase
New Contributor I
1,261 Views

I used the Cobalt Blue formatting tools back in DEC VAX/VMS times, but they stopped to support newer language constructs of Fortran 90/95/2003/2008. SoI  had to switch to plusFort. I am not sure if plusFort is already on the language level which is available in the most recent Intel compiler. But just ask, the people at polyhedron Software are known to be very friendly and helpful. A search in WWW will provide you the necessary URL.

0 Kudos
Reply