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

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++. 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

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

On Wednesday, October 26, 2022 at 9:38:40 AM UTC-7, rym...@outlook.com 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++.
(snip)

> 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.
I suspect that there are many different reasons, so no easy answer.

> 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.

So, converting Fortran 66 style DO loops to DO/ENDDO, and IF to
IF/THEN/ELSE? Or to array expressions instead of loops?

That can make it a lot more readable, but not so much more.

Does it also now use dynamically allocated memory?

> 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.

Well, one reason might be that there are more people interested in
working on the C++ version. That is pretty much independent of the
features and abilities of the languages.

> Is there a reason such as availability of certain libraries or code efficiency that
> you want to convert all your F77 code to C++?
Some of the C++ libraries are likely already translation from Fortran.

> 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.

gfortran can easily run F77 code on any of those systems.

Last year I had IBM's ECAP running on gfortran. That goes back to
Fortran II days, though was translated to Fortran IV pretty far back.,

There were a few complications in doing it, but not much.

I also had Spice 2g6 running, the last of the Fortran Spice versions.

> 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.

If you aren't already into C or C++, not much reason to do it.
Well, maybe as a reason to learn/improve your C++ skills.

Otherwise, you can slowly convert to newer forms as you feel
like it, and keep the old ones running as they are.

On 10/26/2022 11:38 AM, Jeff Ryman 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++. 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
>
> 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

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.

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

On 10/23/2022 3:16 PM, 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++.  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.

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

On Thursday, October 27, 2022 at 11:59:02 AM UTC+11, 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.
..
That was never anything of significance in any version of Fortran.
..
> 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.
..
That was true for FORTRAN 77, but it is not true from Fortran 90.
..
> > This killed our
> > port to gfortran several years ago
..
There was nothing in that that would have been cause for "killing"
a port to gfortran.
..
> 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.
>
> > 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.
..
An inappropriate conclusion.
..
> 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.

On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote:
> On 10/26/2022 7:59 PM, gah4 wrote:
..
> > 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 ?
..
I think the question that you should be asking yourself is
"would you really write a 750,000 line calculation engine in C++ ?"

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.

Lynn McGuire <lynnmcguire5@gmail.com> writes:
>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 ?
>

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 :-)

Lynn McGuire <lynnmcguire5@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."

On 10/27/2022 1:21 PM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@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."

Yeah, I ripped out the overstrike characters years ago. But when one
has over 10,000 format statements, removing the carriage control
character is a lot of work.

My code ran fine using the old F77 compiler on Unix. So it should run
fine if that compiler is available.

Thanks,
Lynn

On 10/27/2022 12:26 AM, Chris M. Thomasson wrote:
> On 10/23/2022 3:16 PM, 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++.  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.
>
> Is the code modular so you can port and test just a part of it?

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

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

On 10/27/2022 9:54 AM, Scott Lurndal wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> 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 ?
>>
>
> 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 :-)

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

Lynn

On Wednesday, October 26, 2022 at 4:56:09 PM UTC-4, Lynn McGuire wrote:
> 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.

I disagree. The absence of free Fortran 90+ compilers until g95/gfortran
slowed the adoption of modern Fortran and caused Fortran to lose market
share, since Fortran 77, supported by the free g77, was not an appealing
language.

It's my impression that the commonly used C++ compilers are free ones --
clang, g++, and Microsoft Visual C++, yet C++ is a very popular language.

On Thursday, October 27, 2022 at 11:21:05 AM UTC-7, Thomas Koenig wrote:

(snip)

> 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 Fortran 66 standard has space, 0, 1, +, for skip to the next line,
next next line, next page, and stay on the same line.

I don't know how they work in earlier IBM systems.

For OS/360, you can have "machine carriage control", RECFM=FBM,
where the first column is the actual channel command code.

Unlike ASA, machine codes are print and then move, instead of
move and then print. If you use ASA characters, the OS converts
them at some point, before printing. Otherwise, any characters
not on the print train print as blanks, including backspace, new
line, carriage return, and line feed.

As for Fortran programs, mostly it means 1X, at the beginning
of most FORMAT strings.

On 10/27/2022 2:56 AM, Robin Vowels wrote:
> On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote:
>> On 10/26/2022 7:59 PM, gah4 wrote:
> .
>>> 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 ?
> .
> I think the question that you should be asking yourself is
> "would you really write a 750,000 line calculation engine in C++ ?"

Since I am doing that, yes, in a heartbeat.

BTW, this is actually the third software program that I have converted
to C or C++. This is the biggest by far. My first was:
https://www.winsim.com/steam/steam.html

Thanks,
Lynn

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> On 10/27/2022 2:56 AM, Robin Vowels wrote:
>> On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote:
>>> On 10/26/2022 7:59 PM, gah4 wrote:
>> .
>>>> 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 ?
>> .
>> I think the question that you should be asking yourself is
>> "would you really write a 750,000 line calculation engine in C++ ?"
>
> Since I am doing that, yes, in a heartbeat.
>
> BTW, this is actually the third software program that I have converted
> to C or C++. This is the biggest by far. My first was:
> https://www.winsim.com/steam/steam.html

That looks nice, steam properties are something that you sometimes
need...

One of the first applied programs I ever wrote was the simulation
for a steam turbine. For his job, my father had a MS-DOS program
which calculated steam properties (you could add the usual values,
and it would calculate the rest). Via a MS-DOS batch file, I
then wrote a program to calculate steam turbine expansion if an
isentropic efficiency was given.

Another story along these lines... quite some years ago, we
were sitting in a conference room, and the question came up what
temperature corresponded to a certain steam pressure in one of
our plants. A colleague from Thailand then took a steam table
out of his shirt pocket and supplied the answer. Never leave
home without it :-)

On 10/29/2022 9:08 AM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> On 10/27/2022 2:56 AM, Robin Vowels wrote:
>>> On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote:
>>>> On 10/26/2022 7:59 PM, gah4 wrote:
>>> .
>>>>> 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 ?
>>> .
>>> I think the question that you should be asking yourself is
>>> "would you really write a 750,000 line calculation engine in C++ ?"
>>
>> Since I am doing that, yes, in a heartbeat.
>>
>> BTW, this is actually the third software program that I have converted
>> to C or C++. This is the biggest by far. My first was:
>> https://www.winsim.com/steam/steam.html
>
> That looks nice, steam properties are something that you sometimes
> need...
>
> One of the first applied programs I ever wrote was the simulation
> for a steam turbine. For his job, my father had a MS-DOS program
> which calculated steam properties (you could add the usual values,
> and it would calculate the rest). Via a MS-DOS batch file, I
> then wrote a program to calculate steam turbine expansion if an
> isentropic efficiency was given.
>
> Another story along these lines... quite some years ago, we
> were sitting in a conference room, and the question came up what
> temperature corresponded to a certain steam pressure in one of
> our plants. A colleague from Thailand then took a steam table
> out of his shirt pocket and supplied the answer. Never leave
> home without it :-)

Yup, the old Combustion Engineering Steam Table pamphlets. A CE boiler
guy would stop by and hand them out like candy. I have 2 or 3 of them
still. They are the 1967 ASME steam table which my software is. I have
a program that calculates steam turbine efficiency called Isencalc
available on that page. Someday I am going to convert it from DOS to Win32.
https://www.amazon.com/Steam-Tables-Properties-Saturated-Superheated/dp/B003O5S3ZW/

My process simulation software has the 1991 Steam Tables in it along
with 60 other equations of state.
https://www.winsim.com/index.html

Lynn

On 10/29/2022 1:59 PM, Lynn McGuire wrote:
> On 10/29/2022 9:08 AM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>> On 10/27/2022 2:56 AM, Robin Vowels wrote:
>>>> On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote:
>>>>> On 10/26/2022 7:59 PM, gah4 wrote:
>>>> .
>>>>>> 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 ?
>>>> .
>>>> I think the question that you should be asking yourself is
>>>> "would you really write a 750,000 line calculation engine in C++ ?"
>>>
>>> Since I am doing that, yes, in a heartbeat.
>>>
>>> BTW, this is actually the third software program that I have converted
>>> to C or C++.  This is the biggest by far.  My first was:
>>>      https://www.winsim.com/steam/steam.html
>>
>> That looks nice, steam properties are something that you sometimes
>> need...
>>
>> One of the first applied programs I ever wrote was the simulation
>> for a steam turbine.  For his job, my father had a MS-DOS program
>> which calculated steam properties (you could add the usual values,
>> and it would calculate the rest).  Via a MS-DOS batch file, I
>> then wrote a program to calculate steam turbine expansion if an
>> isentropic efficiency was given.
>>
>> Another story along these lines... quite some years ago, we
>> were sitting in a conference room, and the question came up what
>> temperature corresponded to a certain steam pressure in one of
>> our plants.  A colleague from Thailand then took a steam table
>> out of his shirt pocket and supplied the answer.  Never leave
>> home without it :-)
>
> Yup, the old Combustion Engineering Steam Table pamphlets.  A CE boiler
> guy would stop by and hand them out like candy.  I have 2 or 3 of them
> still.  They are the 1967 ASME steam table which my software is.  I have
> a program that calculates steam turbine efficiency called Isencalc
> available on that page.  Someday I am going to convert it from DOS to
> Win32.
>
> https://www.amazon.com/Steam-Tables-Properties-Saturated-Superheated/dp/B003O5S3ZW/
>
> My process simulation software has the 1991 Steam Tables in it along
> with 60 other equations of state.
>    https://www.winsim.com/index.html
>
> Lynn
>
CO2 is the wave of the future, any adaptations?

On 10/27/2022 1:21 PM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@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."

We have had almost a hundred programmers over the years, mostly chemical
and mechanical engineers from a dozen countries. The code reads like a
very diverse document. The subroutine names are very ... interesting.

Lynn

On 10/29/2022 2:13 PM, Gary Scott wrote:
> On 10/29/2022 1:59 PM, Lynn McGuire wrote:
>> On 10/29/2022 9:08 AM, Thomas Koenig wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>> On 10/27/2022 2:56 AM, Robin Vowels wrote:
>>>>> On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire
>>>>> wrote:
>>>>>> On 10/26/2022 7:59 PM, gah4 wrote:
>>>>> .
>>>>>>> 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 ?
>>>>> .
>>>>> I think the question that you should be asking yourself is
>>>>> "would you really write a 750,000 line calculation engine in C++ ?"
>>>>
>>>> Since I am doing that, yes, in a heartbeat.
>>>>
>>>> BTW, this is actually the third software program that I have converted
>>>> to C or C++.  This is the biggest by far.  My first was:
>>>>      https://www.winsim.com/steam/steam.html
>>>
>>> That looks nice, steam properties are something that you sometimes
>>> need...
>>>
>>> One of the first applied programs I ever wrote was the simulation
>>> for a steam turbine.  For his job, my father had a MS-DOS program
>>> which calculated steam properties (you could add the usual values,
>>> and it would calculate the rest).  Via a MS-DOS batch file, I
>>> then wrote a program to calculate steam turbine expansion if an
>>> isentropic efficiency was given.
>>>
>>> Another story along these lines... quite some years ago, we
>>> were sitting in a conference room, and the question came up what
>>> temperature corresponded to a certain steam pressure in one of
>>> our plants.  A colleague from Thailand then took a steam table
>>> out of his shirt pocket and supplied the answer.  Never leave
>>> home without it :-)
>>
>> Yup, the old Combustion Engineering Steam Table pamphlets.  A CE
>> boiler guy would stop by and hand them out like candy.  I have 2 or 3
>> of them still.  They are the 1967 ASME steam table which my software
>> is.  I have a program that calculates steam turbine efficiency called
>> Isencalc available on that page.  Someday I am going to convert it
>> from DOS to Win32.
>>
>> https://www.amazon.com/Steam-Tables-Properties-Saturated-Superheated/dp/B003O5S3ZW/
>>
>> My process simulation software has the 1991 Steam Tables in it along
>> with 60 other equations of state.
>>     https://www.winsim.com/index.html
>>
>> Lynn
>>
> CO2 is the wave of the future, any adaptations?

Of course, we are general purpose process simulator. CO2 was part of
the original package in 1969. It is component #49 out of the original
62. There are almost 1,300 components now.

Lynn