- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page