converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program to C++, part 1

[Lynn McGuire]

We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
lines of code engineering software product to C++. With all that code,
we produce four Win32 EXEs and three Win32 DLLs. My goal is to add four
Win64 EXEs and three Win64 DLLs to the product with the same
capabilities as the Win32 versions (console, windowed, Excel callable,
Excel embeddable). Plus support for Unicode named files and Unicode
file paths.

I am using a customized version of f2c at the moment to automate 60% to
80% of the conversion from F77 to C++. I have added support for
logical*8, changed the output file from *.c to *.cpp, added an include
for the Fable fem.hpp template library, removed the trailing underscores
from the subroutine and common block names, removed the ftnlen arguments
from the character arguments, converted all F77 comments to the //
instead of the /* */, and a few other items. If desired, I am willing
to post a copy of my modified f2c on my website with the source code.
https://netlib.org/f2c/
https://en.wikipedia.org/wiki/F2c

f2c does not get me totally there. The Fortran character strings were
poorly handled so they will probably needed fixing for proper sizing and
alignment. The i/o code is crap so I take the original F77 i/o code and
translate it by hand. The arrays in the argument list are still based
at an index of one so I convert those to base index of zero by hand.
All of the local and common block arrays were converted to a base index
of zero by f2c. I add the new *.cpp file to my Visual Studio project.
I then add the new function prototypes to my prototypes.h file and I add
any new common block structures to my commons.h file. I then compile
and fix until I get a clean compile.

I have converted over 8,000 lines of F77 code to C++ now. Several dozen
subroutines and several dozen common blocks. Most are compiling cleanly
in Visual C++ 2015. My limited testing is working well and I will
expand my testing when I hit 15,000 or 20,000 lines of F77 code
converted. I hoping to get a complete build of the smaller of the Win32
DLLs by the end of the year and a full build by next June. One of my
programmers thinks that we will be lucky to get a complete build by late
2024.

Lynn

[Tim Rentsch]

Lynn McGuire <lynnmc...@gmail.com> writes:

> We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++

> lines of code engineering software product to C++. [...]

Which makes the posting not topical for comp.lang.c.

[Lynn McGuire]

I included the comp.lang.c group for the noted usage of f2c.

Lynn

[Lynn McGuire]

On 10/26/2022 11:38 AM, Jeff Ryman wrote:

> I'm not trying to be a smart ass or a troll and I'm not trying to change your mind.
> I'm wondering why you want to convert all of the F77 to C++ rather than to
> modern Fortran that can call or be called from the existing C++ routines.
>
> As a side note, I used to work for a group at Oak Ridge National Laboratory
> (ORNL) that developed the SCALE code system that is used for nuclear analysis.
> A lot of effort was spent many years ago converting it from F77 to Fortran 9x.
> Now, after addition of a number of computer science trained staff to that group
> over the years from the late 1990s to the present, everything is slowly being
> converted to C++. A number of the SCALE codes are being changed to run on
> massively parallel machines, but there are libraries for both Fortran and C++
> available for such machines. I have my suspicions why they are converting but
> that is irrelevant here.
>
> Is there a reason such as availability of certain libraries or code efficiency that
> you want to convert all your F77 code to C++?
>
> The reason I am interested is that I have some old F77 code that ran on IBM
> mainframes, Unix workstations, and DOS PCs which I want to document and
> revive to run on Windows and Linux now that I am retired and have the time.
>
> I had a C/C++ class in the late 1990s but never used any of it at work. I am
> taking some online self study classes in C/C++ so that I can at least read a
> little of existing codes and use it in my project if I find it useful.
>
> Thanks for your consideration.
>
> Jeff

We are having trouble maintaining a mixed Fortran and C++ software
product so I have decided to jump all the way to C++. I like using an
IDE (I first used Turbo Pascal in 1983) and feel that they are
incredibly productive for larger software products. The premier IDE on
Windows is Visual Studio which has some support for Intel Fortran but it
is poor at best when mixed with C++.

We used three features in our F66 / F77 code which are turning out to be
problematic in porting to a new Fortran compiler that supports 64 bit
software. The first is the carriage control option in printing to
stdout or a file. This was never a Fortran standard feature but
everyone used it back in the 1960s, 1970s, and 1980s. This killed our
port to gfortran several years ago but it is now supported there
reputedly. We are ripping it out of our formats as a part of our
conversion to C++.

We use zero initialization of all global and local variables. This
killed our first port to Intel Fortran in 2005 ??? when it uncovered a
linker bug / crash. We have removed the need for this from a portion of
our Fortran code but will be a problem in the C++ conversion.

We use Fortran structures, popularized by DEC back in the 1970s and
1980s, but they never became part of the Fortran standard. We are
converting our structure code to integer*8 and logical*8 as a part of
the C++ port.

Almost all of the Fortran compilers are now free. This is a bad sign,
especially since Intel Fortran, the premier Fortran compiler, just
jumped to free. To me, this says that future of Fortran is cloudy at best.

Nothing in this world is perfect but moving to a single programming
language should help us in the long run. Our software is embeddable in
Excel or can embed Excel in itself, all my glue code is in C++ which
really points the direction to me.

Thanks,
Lynn

[Lynn McGuire]

On 10/26/2022 7:59 PM, gah4 wrote:
> On Wednesday, October 26, 2022 at 1:56:09 PM UTC-7, Lynn McGuire wrote:
>
> (snip)

>
>> We used three features in our F66 / F77 code which are turning out to be
>> problematic in porting to a new Fortran compiler that supports 64 bit
>> software. The first is the carriage control option in printing to
>> stdout or a file. This was never a Fortran standard feature but
>> everyone used it back in the 1960s, 1970s, and 1980s.
>

> It is in the Fortran 66 standard with "when formatted records are
> prepared for printing". For one, you could argue that not all are
> being prepared for printing, at least not in the Fortran 66 sense.
>
> For IBM OS/360 and successors, it is not part of Fortran but of
> the OS. If the DCB has RECFM=FBA you get them, if FB you don't.
>
> But the is reminding me of a Fortran to C port in about 1987.
>
> The C code had a tendency to write the '\n' at the beginning
> of a printf() call, instead of at the end. Sometime later, those
> all got fixed, but it was related to the way that Fortran I/O
> always starts on a new line, and C doesn't do that.

>
>> This killed our
>> port to gfortran several years ago but it is now supported there
>> reputedly. We are ripping it out of our formats as a part of our
>> conversion to C++.
>

> Well, the C/Unix tradition was to write '\f' (form feed characters)
> to the file. I always thought that seemed less standardized
> than ASA characters. Also, there is a Unix program to convert
> from ASA characters.
>
> In any case, yes, I always found ASA control characters funny
> when using interactive terminals for output devices. They are
> fine for line printers, though.
>
> (snip)

>> Almost all of the Fortran compilers are now free. This is a bad sign,
>> especially since Intel Fortran, the premier Fortran compiler, just
>> jumped to free. To me, this says that future of Fortran is cloudy at best.
>

> Seems to me like web browsers are now always free. Pay ones can't
> compete with free ones.

>
>> Nothing in this world is perfect but moving to a single programming
>> language should help us in the long run. Our software is embeddable in
>> Excel or can embed Excel in itself, all my glue code is in C++ which
>> really points the direction to me.
>

> I think if I was in the mood for doing it, it would be Java and not C++,
> but then that is just me.

Would you really write a 750,000 line calculation engine in Java ?

Lynn

[Chris M. Thomasson]

Is the code modular so you can port and test just a part of it?

[Scott Lurndal]

I wouldn't have written a 750,000 line engine in any language;
not as a single module anyway.

You can probably do the whole thing in something like MatLab
in a couple hundred lines :-)

[Thomas Koenig]

Lynn McGuire <lynnmc...@gmail.com> schrieb:

> We used three features in our F66 / F77 code which are turning out to be
> problematic in porting to a new Fortran compiler that supports 64 bit
> software. The first is the carriage control option in printing to
> stdout or a file. This was never a Fortran standard feature but
> everyone used it back in the 1960s, 1970s, and 1980s. This killed our
> port to gfortran several years ago but it is now supported there
> reputedly.

I am not sure how compiler support of ASA carriage control
by a compiler is supposed to look like (apart from the
mandated leading space in free-form output).

The traditional UNIX way is to pipe it through asa(1), which
emulates the traditional carriage control with overstrike
characters etc. This is reasonably easy to write, I once
wrote such a utility myself (and lost the source) but Debian
has it. Source at https://sources.debian.org/src/asa/1.2-1.1/ .

> We are ripping it out of our formats as a part of our
> conversion to C++.

Good riddance.

> We use zero initialization of all global and local variables. This
> killed our first port to Intel Fortran in 2005 ??? when it uncovered a
> linker bug / crash. We have removed the need for this from a portion of
> our Fortran code but will be a problem in the C++ conversion.

That is a bigger problem.

Not sure if your code runs under Linux. If it does, you might want
to run it under valgrind, which will generate tons of errors if
undefined variables are used.

> We use Fortran structures, popularized by DEC back in the 1970s and
> 1980s, but they never became part of the Fortran standard. We are
> converting our structure code to integer*8 and logical*8 as a part of
> the C++ port.

Huh?

> Almost all of the Fortran compilers are now free. This is a bad sign,
> especially since Intel Fortran, the premier Fortran compiler, just
> jumped to free. To me, this says that future of Fortran is cloudy at best.

Why should this be a bad thing? Intel uses the compiler to sell chips,
and so does IBM for POWER.

> Nothing in this world is perfect but moving to a single programming
> language should help us in the long run. Our software is embeddable in
> Excel or can embed Excel in itself, all my glue code is in C++ which
> really points the direction to me.

In the immortal words of a J3 member...

" Hiring someone else to write your C++ code is probably a good
idea for preserving sanity. Although having to read the code
later will undo any of the previously mentioned benefits."

[Lynn McGuire]

Somewhat. And yes, that is what I am doing. Port for a while and then
test. Port for a while and then test. I have already completed the
first cycle. No showstoppers.

Lynn

[Lynn McGuire]

On 10/27/2022 3:51 AM, gah4 wrote:

> On Sunday, October 23, 2022 at 3:16:48 PM UTC-7, Lynn McGuire wrote:
>> We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
>> lines of code engineering software product to C++.
>

> As some other comments make me wonder, is this really C++,
> or is it more like C.
>
> That is, how many C++ features that are not in C are used.
>
> Many C++ programs do a lot of allocate/deallocate for a very
> short term. That is one reason people complain about the speed
> of C++ code. Not that it is necessary to do that, but some do.
>
> Now, since Fortran 77 doesn't do that, I suspect that your program
> doesn't, but just to be sure.

I can write Fortran in any language. <grin>.

The only real features of C++ that I am using is the strong data typing
and the polymorphism. The strong data typing helps a lot even though it
sometimes invokes strong language from the programmer.

When we ported our Windows user interface from Smalltalk to C++ back in
2001, we went from untyped variables to strongly typed. That really
helped with the port. The amount of code increased from 300,000 lines
of Smalltalk to 450,000 lines of C++. And it ran 100 times faster since
the C++ was not interpreted and not garbage collected like the Smalltalk
code.

Thanks,
Lynn

[Lynn McGuire]

I wish. The thermodynamic flash is over 300,000 lines of F77 code and
2,000+ subroutines by itself.

Lynn

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmc...@gmail.com> spake the secret code
<tj4egb$u68$1...@gioia.aioe.org> thusly:

>We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++

>lines of code engineering software product to C++. [...]

Lynn,

I dropped you a private email with a couple suggestions, but I always
seem to end up in people's spam folders, so just a little FYI
publicly.

--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Lynn McGuire]

On 10/27/2022 3:42 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Lynn McGuire <lynnmc...@gmail.com> spake the secret code
> <tj4egb$u68$1...@gioia.aioe.org> thusly:
>
>> We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
>> lines of code engineering software product to C++. [...]
>
> Lynn,
>
> I dropped you a private email with a couple suggestions, but I always
> seem to end up in people's spam folders, so just a little FYI
> publicly.

Hi Richard,

I appreciate the suggestions.

Benchmarking our software against previous known good results is a great
idea. In fact, we have been doing that for around 30 years now. I even
wrote my own comparison tool to cut down on the noise as the benchmarks
produce 400+ MB of text output that we analyze before each release.

Sincerely,
Lynn McGuire

[Lynn McGuire]

On 10/27/2022 3:42 PM, Richard wrote:

> [Please do not mail me a copy of your followup]
>
> Lynn McGuire <lynnmc...@gmail.com> spake the secret code
> <tj4egb$u68$1...@gioia.aioe.org> thusly:
>
>> We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
>> lines of code engineering software product to C++. [...]
>
> Lynn,
>
> I dropped you a private email with a couple suggestions, but I always
> seem to end up in people's spam folders, so just a little FYI
> publicly.

BTW, this software was started in 1965 on the Univac 1108. It has been
ported to many platforms over the years. I ported it to the CDC 7600 in
1976 IIRC. It is currently at version 16.15. This is the first
conversion to another software language though as it was pure Fortran
until 1994.

Thanks,
Lynn

[Tim Rentsch]

The original f2c is incidental to the question you are asking.
Crossposting to comp.lang.c because of f2c is like crossposting
any C++ question because cfront was originally written in C.
This thread is not topical in comp.lang.c, and should not have
been posted there.

[Ross A. Finlayson]

Stratego/XT?

(Re-writing system.)