Does anyone have experience with moving a large code set from
a f77 compiler (open watcom f77) to a modern day fortran 2003
compiler such as IVF ?  I am interested in speeding up the code
execution.  This is double precision floating point bound code
(from our testing in the past).

The code set is about 600,000 lines of f66 / f77 code.  The code
set currently requires zero initialization and saving of all
local variables.  There are about 10,000 lines of c and c++ code
interspersed throughout the f77 code.  The f77 code is all
double precision and arrays are hand looped.

I have tried to port the code to IVF in the past but have run
into trouble with the zero initialization code in IVF.

The open watcom f77 compiler was the premier 32 bit compiler in
it's day but that day has long passed.  No array optimizations,
no matrix specializations, etc.  Automatic parallelisms would
be nice but I doubt that the current code would lend itself
easily to these.

Sincerely,
Lynn McGuire

Lynn McGuire wrote:
> Does anyone have experience with moving a large code set from
> a f77 compiler (open watcom f77) to a modern day fortran 2003
> compiler such as IVF ?  ...

Lynn, I'll make some of the same comments I've made in the OW forum...

I have little doubt that generically speaking IVF is now more capable 
optimizing than was Watcom then but if your compute routines are still 
going to rely on the previously discussed usage of the home-rolled C 
malloc'ed dynamic memory it may not be of as much benefit might 
otherwise be.

OTOH, if that memory allocation is at a higher level and you simply pass 
arrays and look within the subroutines that have those arrays as dummy 
arguments, then you may see some benefits of more modern optimization 
techniques as well as taking better advantage of current hardware 
capabilities.

We've had the generic discussion multiple times in the past but I've 
never actually seen any of the code to look at specifically.

I'd again reiterate that the only way you'll be able to know for sure 
will be to take some representative portions of the code that are able 
to be compiled and run w/ the two and compare the results empirically.

--

On 6/14/2010 11:02 AM, Lynn McGuire wrote:
> Does anyone have experience with moving a large code set from
> a f77 compiler (open watcom f77) to a modern day fortran 2003
> compiler such as IVF ? I am interested in speeding up the code
> execution. This is double precision floating point bound code
> (from our testing in the past).
>
> The code set is about 600,000 lines of f66 / f77 code. The code
> set currently requires zero initialization and saving of all
> local variables. There are about 10,000 lines of c and c++ code
> interspersed throughout the f77 code. The f77 code is all
> double precision and arrays are hand looped.
>
> I have tried to port the code to IVF in the past but have run
> into trouble with the zero initialization code in IVF.
>
> The open watcom f77 compiler was the premier 32 bit compiler in
> it's day but that day has long passed. No array optimizations,
> no matrix specializations, etc. Automatic parallelisms would
> be nice but I doubt that the current code would lend itself
> easily to these.
>
> Sincerely,
> Lynn McGuire

A code of the size that you have, especially if it is monolithic rather 
than modular, is going to involve a substantial amount of effort to 
convert from F77 to F2003 or F95, even if you use tools to do the bulk 
of the conversion. There is a definite possibility that the code, after 
conversion, will run slightly _slower_. Are you prepared for that?

On the other hand, if, as part of the conversion, you undertake to 
re-examine the underlying algorithms, and review the code for its being 
suited for a modern, large shared memory, multi-level cache and 
multiprocessor target architecture, you may obtain speed gains of one or 
more orders of magnitude.

Let me give you an example. There is a NASA Lewis combustion code, 
called CEA, which is in F77. One of the things it does is to read 
thermochemical properties from an unformatted file. However, every time 
it needs the property of one species, it rewinds and reads the file 
until it finds the record of interest. When the program was originally 
written, there would not have been enough memory ("core") to hold all 
the needed data for hundreds of species. Today, however, it is enough to 
read all the dat into memory in one slurp, just once. The resulting 
speed increase (new F95 version versus old F77 version) was tenfold.

Another example, from the same code conversion as in the previous 
paragraph. Some variables were used without initialization (or relied on 
incorrect zero initialization,  which many old Fortran compilers 
provided as default). Fixing these bugs made the iterative solutions 
converge in fewer iterations.

There is a class of program bugs which tend not to draw enough attention 
to become candidates for fixing: bugs that slow the program down without 
affecting the correctness of results.

If your program uses, say, multivariable optimization, using a modern 
algorithm in place of one that was available in 1970, say, may well 
yield a ten- or hundred-fold speed up.

Another issue is maintainability. As they say, it is possible to write 
spaghetti-Basic in any programming language. The more complete interface 
and type checking, the INTENT feature for arguments, the new structured 
programming features will make your code more maintainable after conversion.

In summary, a mere conversion from F77 to F95/F2K is probably not 
justified if your code uses efficient algorithms that have been 
correctly implemented. Sorry, no silver bullet here.

-- mecej4

On 6/14/2010 9:02 AM, Lynn McGuire wrote:
> Does anyone have experience with moving a large code set from
> a f77 compiler (open watcom f77) to a modern day fortran 2003
> compiler such as IVF ? I am interested in speeding up the code
> execution.
>
> The code set is about 600,000 lines of f66 / f77 code. The code
> set currently requires zero initialization and saving of all
> local variables.
>
> I have tried to port the code to IVF in the past but have run
> into trouble with the zero initialization code in IVF.
>

Dependence on default SAVE syntax has been an obstacle to optimization 
for over 2 decades.  This is why it was never part of the Fortran 
standard, and (from f77 on) better alternatives are offered.  Default 
SAVE was a response to the widespread (but not universal) use of such an 
extension under f66.  ifort does a reasonable job of emulating the 
default SAVE behavior of its predecessor, when the associated options 
are set, but that will make further optimizations difficult, as those 
options are incompatible with parallelization.  At least on the C side, 
improved options are available for catching such dependencies.
Since you bring up C++, most C++ programs written prior to the 
institution of C++ standards, or not checked for portability, are likely 
to require significant updating, regardless of your compiler choice.

-- 
Tim Prince

Lynn McGuire <lmc@winsim.com> wrote:

> Does anyone have experience with moving a large code set from
> a f77 compiler (open watcom f77) to a modern day fortran 2003
> compiler such as IVF ?  I am interested in speeding up the code
> execution.  This is double precision floating point bound code
> (from our testing in the past).

Others have made some good suggestions, I will add a few
different ones.
 
> The code set is about 600,000 lines of f66 / f77 code.  The code
> set currently requires zero initialization and saving of all
> local variables.  There are about 10,000 lines of c and c++ code
> interspersed throughout the f77 code.  The f77 code is all
> double precision and arrays are hand looped.

Assuming the loops are in the right order, in most cases
hand-looped code is at least as fast as array operations.

Using array operations often uses temporary arrays, for
example, where DO loops won't need them.  Now, if you
are running on a Cray vector processor, and the DO loops
don't vectorize but array operations do, then maybe, but
that is rare.

There is one thing that lasted way too long in both Fortran
and C, especially on windows machines, and that is allocating
REAL*8 on odd four byte boundary.  On the 80486, with a 32 bit
data bus, that was fine, but it wasn't changed when the pentium
came out, and the speed difference is fairly large.

That doesn't require a new compiler, though.
 
> I have tried to port the code to IVF in the past but have run
> into trouble with the zero initialization code in IVF.
 
> The open watcom f77 compiler was the premier 32 bit compiler in
> it's day but that day has long passed.  No array optimizations,
> no matrix specializations, etc.  Automatic parallelisms would
> be nice but I doubt that the current code would lend itself
> easily to these.

The "whole program" optimization of some of the newer compilers
can speed up things considerably, especially inlining of
functions that are fast but called many times.  Also, inlining
allows for some optimizations that otherwise aren't possible.

-- glen

Lynn McGuire wrote:
> Does anyone have experience with moving a large code set from
> a f77 compiler (open watcom f77) to a modern day fortran 2003
> compiler such as IVF ?  I am interested in speeding up the code
> execution.  This is double precision floating point bound code
> (from our testing in the past).

> I have tried to port the code to IVF in the past but have run
> into trouble with the zero initialization code in IVF.

Doesn't "-zero" work? I do not know the code, but some code also needs
-save.

(In gfortran, the options are called -finit-local-zero and [only if SAVE
is required!] -fno-automatic.)

 * * *

Regarding automatic parallelization: My feeling is that it often does
not work and can even make your program slower. However, what usually
helps with speeding up is vectorization - which is also a kind of
parallelization (though on processor/SSE level) - but that's still using
only one core.

Tobias

In article <4C168BA3.3060508@net-b.de>,
 Tobias Burnus <burnus@net-b.de> wrote:

> Lynn McGuire wrote:
> > Does anyone have experience with moving a large code set from
> > a f77 compiler (open watcom f77) to a modern day fortran 2003
> > compiler such as IVF ?  I am interested in speeding up the code
> > execution.  This is double precision floating point bound code
> > (from our testing in the past).
> 
> > I have tried to port the code to IVF in the past but have run
> > into trouble with the zero initialization code in IVF.
> 
> Doesn't "-zero" work? I do not know the code, but some code also needs
> -save.
> 
> (In gfortran, the options are called -finit-local-zero and [only if SAVE
> is required!] -fno-automatic.)

I would suggest to the OP to correct this known bug in the program 
as quickly as possible.  Of course, a known bug is easier to work 
with than unknown bugs, but sill, a bug is a bug, and there is no 
guarantee that future compiles will work as wanted on code that has 
these kinds of bugs.

If you have a compiler that produces correct results with one set of 
standard-violating compiler options but incorrect results with 
standard-conforming options, then this is actually a good situation.  
You can compile various parts of your code with and without the 
options and zero in on where the error in the code is located.  And 
once located, it can be fixed (in this case, by saving the necessary 
variables and setting variables to correct initial values).


> Regarding automatic parallelization: My feeling is that it often does
> not work and can even make your program slower. However, what usually
> helps with speeding up is vectorization - which is also a kind of
> parallelization (though on processor/SSE level) - but that's still using
> only one core.

When I read the original post, the first thing I though was that a 
modern compiler is more likely to use SSE instructions than an older 
compiler, especially the newer SSE3 and SSE4 instructions.  If you 
have tight well-written do loops, then this is likely to result in 
significant performance improvements, even without changing any of 
the code, but perhaps some tweaking of the code might help this 
process even more.  There are also memory-related optimizations that 
can be done on modern compilers to account for cache effects on 
newer hardware.

$.02 -Ron Shepard

>> I have tried to port the code to IVF in the past but have run
>> into trouble with the zero initialization code in IVF.
>
> Doesn't "-zero" work? I do not know the code, but some code also needs
> -save.

It does but only mostly.  I cannot remember at this time but
some variables (maybe arrays ?) were not initialized to zero
and that killed my app.

> Regarding automatic parallelization: My feeling is that it often does
> not work and can even make your program slower. However, what usually
> helps with speeding up is vectorization - which is also a kind of
> parallelization (though on processor/SSE level) - but that's still using
> only one core.

I suspected as much.  Yes, I think that automatic vectorization
would help, the question is just how much.

Thanks,
Lynn

> Dependence on default SAVE syntax has been an obstacle to optimization for over 2 decades. This is why it was never part of the
> Fortran standard, and (from f77 on) better alternatives are offered. Default SAVE was a response to the widespread (but not
> universal) use of such an extension under f66. ifort does a reasonable job of emulating the default SAVE behavior of its predecessor,
> when the associated options are set, but that will make further optimizations difficult, as those options are incompatible with
> parallelization. At least on the C side, improved options are available for catching such dependencies.

I suspect that we need to remove the zero init and default save
requirements from the code in order to move forward on this
problem.

Thanks,
Lynn

> When I read the original post, the first thing I though was that a
> modern compiler is more likely to use SSE instructions than an older
> compiler, especially the newer SSE3 and SSE4 instructions.  If you
> have tight well-written do loops, then this is likely to result in
> significant performance improvements, even without changing any of
> the code, but perhaps some tweaking of the code might help this
> process even more.  There are also memory-related optimizations that
> can be done on modern compilers to account for cache effects on
> newer hardware.

We have sloppy, thousands of lines of code with multitudes of
subroutine calls, do loops all over the place.  All of our
floating point is in double precision.  I would like to see the
effects of the SSE instructions but I need get a fully working
version of the code in IVF first.  It goes without saying that
Open Watcom F77 does not have a clue about the SSE instructions.

Thanks,
Lynn

> OTOH, if that memory allocation is at a higher level and you simply pass arrays and look within the subroutines that have those
> arrays as dummy arguments, then you may see some benefits of more modern optimization techniques as well as taking better advantage
> of current hardware capabilities.

Yes, it is.  The f77 code never sees the actual memory pointer
from malloc or realloc, the f77 code gets an offset pointer to
an array in a common block.  That offset pointer can be positive
or negative !

> We've had the generic discussion multiple times in the past but I've never actually seen any of the code to look at specifically.

I'm always willing to show parts of the code but I have no idea
what would help.  Our main nonlinear solver (we have several in
the app), is over 1,000 subroutines and around 200,000 lines of
code.  It is very difficult to understand the code as the main
subroutine is 5000+ lines itself and very featured (complicated).

> I'd again reiterate that the only way you'll be able to know for sure will be to take some representative portions of the code that
> are able to be compiled and run w/ the two and compare the results empirically.

As I mentioned in openwatcom.users.fortran, we are adding a
cache to one of nonlinear solvers.  This particular function
is at the heart of our app with hundreds of thousands of calls
to it in a large flowsheet.

Thanks,
Lynn

Lynn McGuire wrote in message ...
>>> I have tried to port the code to IVF in the past but have run
>>> into trouble with the zero initialization code in IVF.
>>
>> Doesn't "-zero" work? I do not know the code, but some code also needs
>> -save.
>
>It does but only mostly.  I cannot remember at this time but
>some variables (maybe arrays ?) were not initialized to zero
>and that killed my app.

What killed your app was uninitialized variables,
which is a programming error.
The remedy is, of course, to initilaiize them.

>> It does but only mostly.  I cannot remember at this time but
>> some variables (maybe arrays ?) were not initialized to zero
>> and that killed my app.
>
> What killed your app was uninitialized variables,
> which is a programming error.
> The remedy is, of course, to initilaiize them.

Uh yes, sure.  All 300,000 of them.  While differentiating
the ones that need to maintain their values between subroutine
calls.

It is not a trivial task.  That is why the save and zero init
work so well for us.  And, I suspect that the number of variables
that need their values saved between subroutine calls are actually
less than 100.

Thanks,
Lynn

On Jun 16, 11:39=A0am, Lynn McGuire <l...@winsim.com> wrote:
> >> It does but only mostly. =A0I cannot remember at this time but
> >> some variables (maybe arrays ?) were not initialized to zero
> >> and that killed my app.
>
> > What killed your app was uninitialized variables,
> > which is a programming error.
> > The remedy is, of course, to initilaiize them.
>
> Uh yes, sure. =A0All 300,000 of them. =A0While differentiating
> the ones that need to maintain their values between subroutine
> calls.
>
> It is not a trivial task. =A0That is why the save and zero init
> work so well for us. =A0And, I suspect that the number of variables
> that need their values saved between subroutine calls are actually
> less than 100.
>
> Thanks,
> Lynn

Is there some practical way to run individual routines though a
checkout compiler so that you can at least find those variables that
are NOT initialized?

IIRC Watfor had this capability. I don't know about Open Watcom.

I realize that this is a monumental task, but it's sort of like the
national debt. It just keeps getting bigger, it's too large to fail,
and eventually it will have to be dealt with.

--- e

e p chandler wrote:

> On Jun 16, 11:39 am, Lynn McGuire <l...@winsim.com> wrote:
>> >> It does but only mostly.  I cannot remember at this time but
>> >> some variables (maybe arrays ?) were not initialized to zero
>> >> and that killed my app.
>>
>> > What killed your app was uninitialized variables,
>> > which is a programming error.
>> > The remedy is, of course, to initilaiize them.
>>
>> Uh yes, sure.  All 300,000 of them.  While differentiating
>> the ones that need to maintain their values between subroutine
>> calls.
>>
>> It is not a trivial task.  That is why the save and zero init
>> work so well for us.  And, I suspect that the number of variables
>> that need their values saved between subroutine calls are actually
>> less than 100.
>>
>> Thanks,
>> Lynn
> 
> Is there some practical way to run individual routines though a
> checkout compiler so that you can at least find those variables that
> are NOT initialized?
> 
> IIRC Watfor had this capability. I don't know about Open Watcom.
> 
> I realize that this is a monumental task, but it's sort of like the
> national debt. It just keeps getting bigger, it's too large to fail,
> and eventually it will have to be dealt with.
> 
> --- e

Let's hope that you and I don't inherit the pleasure of bailing it out :) !

If, if fact, the conjecture that less than 100 variables need saving is near
the mark, it is not a monumental task -- non-trivial, perhaps, but not
monumental.

-- mecej4

Lynn McGuire <lmc@winsim.com> wrote:
(snip, someone wrote)

>> What killed your app was uninitialized variables,
>> which is a programming error.
>> The remedy is, of course, to initilaiize them.
 
> Uh yes, sure.  All 300,000 of them.  While differentiating
> the ones that need to maintain their values between subroutine
> calls.

I do wonder how hard it would be to write a program to read
the source, and then insert the appropriate DATA statements
to zero and SAVE all such variables.  Somewhat easier for 
variables that already have a declaration.
 
> It is not a trivial task.  That is why the save and zero init
> work so well for us.  And, I suspect that the number of variables
> that need their values saved between subroutine calls are actually
> less than 100.

-- glen

e p chandler <epc8@juno.com> wrote:
(snip)
 
> Is there some practical way to run individual routines though a
> checkout compiler so that you can at least find those variables that
> are NOT initialized?
 
> IIRC Watfor had this capability. I don't know about Open Watcom.

I once ran a few thousand line program through WATFIV to find
uninitialized variables.  Compared to Fortran H it compiled about
ten times faster, and ran about ten times slower.  
 
> I realize that this is a monumental task, but it's sort of like the
> national debt. It just keeps getting bigger, it's too large to fail,
> and eventually it will have to be dealt with.

It would be a nice feature to have in at least one compiler.
Another possibility would be a source to source translator
that would take Fortran source as input and generate Fortran
source with the appropriate checks as output.  In this case,
it would have to initialize all variables to some rare value,
and then IF statements before every access to check for that
value.  Not easy, but not so hard, either.  

-- glen

glen herrmannsfeldt wrote:
> e p chandler <epc8@juno.com> wrote:
> (snip)
>  
>> Is there some practical way to run individual routines though a
>> checkout compiler so that you can at least find those variables that
>> are NOT initialized?
>  
>> IIRC Watfor had this capability. I don't know about Open Watcom.
> 
> I once ran a few thousand line program through WATFIV to find
> uninitialized variables.  Compared to Fortran H it compiled about
> ten times faster, and ran about ten times slower.  
>  
>> I realize that this is a monumental task, but it's sort of like the
>> national debt. It just keeps getting bigger, it's too large to fail,
>> and eventually it will have to be dealt with.
> 
> It would be a nice feature to have in at least one compiler.
> Another possibility would be a source to source translator
> that would take Fortran source as input and generate Fortran
> source with the appropriate checks as output.  In this case,
> it would have to initialize all variables to some rare value,
> and then IF statements before every access to check for that
> value.  Not easy, but not so hard, either.  

While I've not tested them, specifically, the Polyhedron comparison 
chart of features says NAG and Silverfrost (nee Salford) both do both 
static and runtime initialization checks for almost, if not quite all.

I've suggested to Lynn in the OW forum the investment in another 
compiler that has such facilities would likely pay a significant ROI.

--

>> Uh yes, sure.  All 300,000 of them.  While differentiating
>> the ones that need to maintain their values between subroutine
>> calls.
>
> I do wonder how hard it would be to write a program to read
> the source, and then insert the appropriate DATA statements
> to zero and SAVE all such variables.  Somewhat easier for
> variables that already have a declaration.

I have no idea which are the 100 of the 300,000 variables that
we need to save between the subroutine calls.  That is the
tough part.  Otherwise the init to zero data statements are a
simple perl script.

The determination of the 100 (or 1000, I really have no idea)
will require removal of the global save command and then massive
testing ... and then determination of what went wrong in some
weird part of one of our nonlinear solvers.  Some very tough
work !

Thanks,
Lynn

On Jun 16, 10:39=A0am, Lynn McGuire <l...@winsim.com> wrote:
> >> It does but only mostly. =A0I cannot remember at this time but
> >> some variables (maybe arrays ?) were not initialized to zero
> >> and that killed my app.
>
> > What killed your app was uninitialized variables,
> > which is a programming error.
> > The remedy is, of course, to initilaiize them.
>
> Uh yes, sure. =A0All 300,000 of them. =A0While differentiating
> the ones that need to maintain their values between subroutine
> calls.
>
> It is not a trivial task. =A0That is why the save and zero init
> work so well for us. =A0And, I suspect that the number of variables
> that need their values saved between subroutine calls are actually
> less than 100.
>
> Thanks,
> Lynn

? Initializing with a data statement only initializes them once, first
time the procedure is called, not upon every entry.

"GaryScott" <garylscott@sbcglobal.net> wrote in message 
news:9f8b26e5-52ba-4a15-ae54-4b22abd95522@q29g2000vba.googlegroups.com...
On Jun 16, 10:39 am, Lynn McGuire <l...@winsim.com> wrote:
> >> It does but only mostly. I cannot remember at this time but
> >> some variables (maybe arrays ?) were not initialized to zero
> >> and that killed my app.
>
> > What killed your app was uninitialized variables,
> > which is a programming error.
> > The remedy is, of course, to initilaiize them.
>
> Uh yes, sure. All 300,000 of them. While differentiating
> the ones that need to maintain their values between subroutine
> calls.
>
> It is not a trivial task. That is why the save and zero init
> work so well for us. And, I suspect that the number of variables
> that need their values saved between subroutine calls are actually
> less than 100.
>
> Thanks,
> Lynn

? Initializing with a data statement only initializes them once, first
time the procedure is called, not upon every entry.

I think the behavior Lynn is depending on is having the variables 
initialized to zero once, then having them saved there after.

e p chandler <epc8@juno.com> wrote:

> I think the behavior Lynn is depending on is having the variables 
> initialized to zero once, then having them saved there after.

Her situation sounds like a nightmare to me. From prior posts, I think I
recall that it wasn't even affirmatively known what was going on. If it
were known, then it would seem much more straightforward to fix. Rather,
I recall that things failed when the magic compiler switches (notably
save and zero-init kinds of switches) were not used, or even on some
compilers where those switches were used. I don't consider that
affirmative knowledge of what is going on, but instead deduction from
observed program behavior, along with speculation to correlate the
failures with the details of how different compilers implement the magic
switches.

I'd worry (a *LOT*) that this implies portions of the code are just
being used as a "black box" without actually having a detailed
understanding and documentation of exactly what the code is doing. It
seems to me that a detailed understanding/documentation would inherently
include information about what program state was initialized/saved.
That's sure part of what I'd consider critical documentation of any code
I wrote.

I'd hate for my job to depend on such a "black box." Since my work
products could cause airplane crashes and kill test pilots if
sufficiently badly messed up (and not otherwise caught - fortunately,
there was lots of checking involved), I'd have even more hated for my
work products to depend on something that wasn't documented better than
it sounds.

I suppose it probably isn't as bad as the impression I sometimes get
from the postings.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 6/16/2010 6:26 PM, e p chandler wrote:
>
> "GaryScott" <garylscott@sbcglobal.net> wrote in message
> news:9f8b26e5-52ba-4a15-ae54-4b22abd95522@q29g2000vba.googlegroups.com...
> On Jun 16, 10:39 am, Lynn McGuire <l...@winsim.com> wrote:
>> >> It does but only mostly. I cannot remember at this time but
>> >> some variables (maybe arrays ?) were not initialized to zero
>> >> and that killed my app.
>>
>> > What killed your app was uninitialized variables,
>> > which is a programming error.
>> > The remedy is, of course, to initilaiize them.
>>
>> Uh yes, sure. All 300,000 of them. While differentiating
>> the ones that need to maintain their values between subroutine
>> calls.
>>
>> It is not a trivial task. That is why the save and zero init
>> work so well for us. And, I suspect that the number of variables
>> that need their values saved between subroutine calls are actually
>> less than 100.
>>
>> Thanks,
>> Lynn
>
> ? Initializing with a data statement only initializes them once, first
> time the procedure is called, not upon every entry.
>
> I think the behavior Lynn is depending on is having the variables
> initialized to zero once, then having them saved there after.
>
Exactly, so a data statement coupled with a global save seems to do 
exactly what is required.
>

In article <hvb6sf$onc$1@speranza.aioe.org>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> 
> It would be a nice feature to have in at least one compiler.
> Another possibility would be a source to source translator
> that would take Fortran source as input and generate Fortran
> source with the appropriate checks as output.  In this case,
> it would have to initialize all variables to some rare value,
> and then IF statements before every access to check for that
> value.  Not easy, but not so hard, either.  

Some compilers have options that allow memory to be set by default to 
particular values.  A particularly useful value on IEEE machines would 
be signaling NAN.  These values produce errors the first time they are 
used, allowing the uninitialized values (in fortran) to be identified.

$.02 -Ron Shepard

> > Initializing with a data statement only initializes them once, first
> > time the procedure is called, not upon every entry.
>
> I think the behavior Lynn is depending on is having the variables initialized
 > to zero once, then having them saved there after.

Very true.  That is the behavior that our code relies on now.

When I come up for air in our current tasks, I am going to turn
off the zero init and the automatic save in the open watcom f77
compiler and see what happens.

Thanks,
Lynn McGuire

"Lynn McGuire" <lmc@winsim.com> wrote in message 
news:ANKdnaz_stuFo4TRnZ2dnUVZ_jidnZ2d@supernews.com...
>>> Uh yes, sure.  All 300,000 of them.  While differentiating
>>> the ones that need to maintain their values between subroutine
>>> calls.
>>
>> I do wonder how hard it would be to write a program to read
>> the source, and then insert the appropriate DATA statements
>> to zero and SAVE all such variables.  Somewhat easier for
>> variables that already have a declaration.
>
> I have no idea which are the 100 of the 300,000 variables that
> we need to save between the subroutine calls.  That is the
> tough part.  Otherwise the init to zero data statements are a
> simple perl script.
>
> The determination of the 100 (or 1000, I really have no idea)
> will require removal of the global save command and then massive
> testing ... and then determination of what went wrong in some
> weird part of one of our nonlinear solvers.  Some very tough
> work !
>
> Thanks,
> Lynn


This requires whole-program analysis and transformation.

There are tools that can do this.

The DMS Software Reengineering Toolkit
(see http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html)
is one of them.  It is general purpose program transformation
machinery, parameterized by explicit langauge definitions.  We have defined 
langauges such as C, C++, COBOL,
PLSQL, Java, C#, for DMS... and have a definition for F77 and F95.
(See 
http://www.semanticdesigns.com/Products/FrontEnds/FortranFrontEnd.html).

We have done mass analysis on C applications of some 25 million lines, 
250,000+ functions.
These anlaysis include data flow analysis; what is needed here is data flow 
analysis from
variables to points of consumption where it is clear the variables are 
uninitialized.  The transformation
is to then insert initialization code for such variables (in this case, 
zeroing).
Fortran is easier than C :-}

Don't get me wrong, this isn't an afternoon's exercise.   But at this kind 
of scale, doing
it by hand is painful and errorprone.

-- IDB

> Does anyone have experience with moving a large code set from
> a f77 compiler (open watcom f77) to a modern day fortran 2003
> compiler such as IVF ? I am interested in speeding up the code
> execution. This is double precision floating point bound code
> (from our testing in the past).

For those who are interested, we approached this another way.  I
had one of my guys add an isothermal flash cache to our general
flash.  The result was that our benchmark execution time went
from 3:15 hours to 1:35 hours.  I was amazed !

Thanks for the input,
Lynn

Lynn McGuire wrote:
....

> had one of my guys add an isothermal flash cache to our general
> flash.  ...

In a quick moment before heading to fields...

I have no clue what you just said???

--

>> had one of my guys add an isothermal flash cache to our general
>> flash. ...
>
> In a quick moment before heading to fields...
>
> I have no clue what you just said???

Our software has a large thermodynamic calculation engine built
into it.  An isothermal flash is performed at a given temperature
and a given pressure.  Given a certain amount of components in a
mixture (water, methane, ethane, propane, butane, pentane, carbon
dioxide, hydrogen sulfide, etc - up to 1,000 components), we will
calculate how much of each component is in the vapor phase, the
hydrocarbon liquid phase and the aqueous liquid phase.

So anyway, we save the results of the calculations now.  If the
flowsheet wants to make the same exact calculation again, we already
have it saved.   Apparently saves a lot of time !

Thanks,
Lynn

On Thu, 24 Jun 2010, Lynn sent:
|----------------------------------------------------------------|
|"> Does anyone have experience with moving a large code set from|
|> a f77 compiler (open watcom f77) to a modern day fortran 2003 |
|> compiler such as IVF ? I am interested in speeding up the code|
|> execution. This is double precision floating point bound code |
|> (from our testing in the past).                               |
|                                                                |
|For those who are interested, we approached this another way."  |
|----------------------------------------------------------------|

Dear Lynn,

Just to clarify: are you staying with Open Watcom F77 and not trying
to port to Fortran 2003? I was awaiting reports of differences in
speed with the Fortran 2003 version. Ah , well.

|----------------------------------------------------------------|
|"  I                                                            |
|had one of my guys add an isothermal flash cache to our general |
|flash.  The result was that our benchmark execution time went   |
|from 3:15 hours to 1:35 hours.  I was amazed !                  |
|                                                                |
|Thanks for the input,                                           |
|Lynn"                                                           |
|----------------------------------------------------------------|

An old technique, but if it works it works!

Yours sincerely,
Colin Paul Gloster

> Just to clarify: are you staying with Open Watcom F77 and not trying
> to port to Fortran 2003? I was awaiting reports of differences in
> speed with the Fortran 2003 version. Ah , well.

For the moment.  Our code just works here.  But, I am considering
trying out the Absoft fortran compiler ( http://absoft.com/ ) as it
has a good rep.

My long term goal is to convert our F77 code to C++ using FOR_C.
We may be trying this later this year when all of our Hollerith
code is gone.

> An old technique, but if it works it works!

I have found that improvements in the algorithm are always superior
to code optimization.  But, the automatic vectorization in Absoft
sounds interesting.

Thanks,
Lynn

On Fri, 25 Jun 2010, Lynn McGuire sent:

|-------------------------------------------------------------------|
|"[..]                                                              |
|                                                                   |
|My long term goal is to convert our F77 code to C++ using FOR_C.   |
|[..]"                                                              |
|-------------------------------------------------------------------|

Using C++ is a bad idea.

|-------------------------------------------------------------------|
|"> An old technique, but if it works it works!                     |
|                                                                   |
|I have found that improvements in the algorithm are always superior|
|to code optimization. [..]                                         |
|[..]"                                                              |
|-------------------------------------------------------------------|

One does not always have that option.

> |My long term goal is to convert our F77 code to C++ using FOR_C.   |
> |[..]"                                                              |
>
> Using C++ is a bad idea.

Why ?  Half of our app is already in C++.  We have 600,000
lines of f77 code and 600,000 lines of c++ code.  The c++
code is far easier to maintain and code in.

Thanks,
Lynn

In article <i02tfs$rv3$1@news.eternal-september.org>,
 Lynn McGuire <lmc@winsim.com> wrote:

> > Using C++ is a bad idea.
> 
> Why ?  Half of our app is already in C++.  We have 600,000
> lines of f77 code and 600,000 lines of c++ code.  The c++
> code is far easier to maintain and code in.

After looking at your f77 code (with all of its nonstandard 
extensions) that you have posted here, I would say that is damnation 
by faint praise.

$.02 -Ron Shepard

On 2010-06-25 20:29:11 -0300, Ron Shepard 
<ron-shepard@NOSPAM.comcast.net> said:

> In article <i02tfs$rv3$1@news.eternal-september.org>,
>  Lynn McGuire <lmc@winsim.com> wrote:
> 
>>> Using C++ is a bad idea.
>> 
>> Why ?  Half of our app is already in C++.  We have 600,000
>> lines of f77 code and 600,000 lines of c++ code.  The c++
>> code is far easier to maintain and code in.
> 
> After looking at your f77 code (with all of its nonstandard
> extensions) that you have posted here, I would say that is damnation
> by faint praise.
> 
> $.02 -Ron Shepard

Les Hatton (he has a web site) has published reports on studies of production
codes in oil exploration. C, C++ and Fortran with Fortran causing least
problems. Various others have reported that C++ is a real bear with
two caveats 1. no use of object inheritance 2. serious objects only
when objects are very well designed such as the (many-ith iteration)
of a design such as windows and the design is now static and widely used.
Basically C++ is impossible to read/maintain is there is any serious
local use of objects as one no longer knows what the code is doing with
only a local inspection.

Lynn McGuire wrote:

<...>
> My long term goal is to convert our F77 code to C++ using FOR_C.
> We may be trying this later this year when all of our Hollerith
> code is gone.
A couple of points to quote in that regard:

    i) Cobalt-Blue's FOR_C is an F77 to C (NOT C++) converter.

    ii) FOR_C may choke on many of the non-standard F77 extensions used in
your code.

-- mecej4

>> My long term goal is to convert our F77 code to C++ using FOR_C.
>> We may be trying this later this year when all of our Hollerith
>> code is gone.
> A couple of points to quote in that regard:
>
>      i) Cobalt-Blue's FOR_C is an F77 to C (NOT C++) converter.

Yes.  But converting C code to C++ code is fairly easy.  I've done
it several times now.  However, converting char * strings to STL
strings is non-trivial but that can be done later.

>      ii) FOR_C may choke on many of the non-standard F77 extensions used in
> your code.

Nope.  FOR_C understands the vax structure, union, map and record
keywords.  That is the only extension that we are currently using.

Thanks,
Lynn

> Les Hatton (he has a web site) has published reports on studies of production
> codes in oil exploration. C, C++ and Fortran with Fortran causing least
> problems. Various others have reported that C++ is a real bear with
> two caveats 1. no use of object inheritance 2. serious objects only
> when objects are very well designed such as the (many-ith iteration)
> of a design such as windows and the design is now static and widely used.
> Basically C++ is impossible to read/maintain is there is any serious
> local use of objects as one no longer knows what the code is doing with
> only a local inspection.

I found it here.  http://www.leshatton.org/  with a specific
1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf .
A lot has changed in fortran and C++ since then.  I will take a
look but we have quite a bit of experience here.

Thanks,
lynn

"Lynn McGuire" <lmc@winsim.com> wrote in message 
news:i02jfd$lmu$1@news.eternal-september.org...
>>> had one of my guys add an isothermal flash cache to our general
>>> flash. ...
>>
>> In a quick moment before heading to fields...
>>
>> I have no clue what you just said???
>
> Our software has a large thermodynamic calculation engine built
> into it.  An isothermal flash is performed at a given temperature
> and a given pressure.  Given a certain amount of components in a
> mixture (water, methane, ethane, propane, butane, pentane, carbon
> dioxide, hydrogen sulfide, etc - up to 1,000 components), we will
> calculate how much of each component is in the vapor phase, the
> hydrocarbon liquid phase and the aqueous liquid phase.
>
> So anyway, we save the results of the calculations now.  If the
> flowsheet wants to make the same exact calculation again, we already
> have it saved.   Apparently saves a lot of time !
>
> Thanks,
> Lynn

supposedly Terje Mathisen once said "All programming is an exercise in 
caching."
 

"mecej4" <mecej4.nyetspam@operamail.com> wrote in message 
news:i03iq8$har$1@news.eternal-september.org...
> Lynn McGuire wrote:
>
> <...>
>> My long term goal is to convert our F77 code to C++ using FOR_C.
>> We may be trying this later this year when all of our Hollerith
>> code is gone.
> A couple of points to quote in that regard:
>
>    i) Cobalt-Blue's FOR_C is an F77 to C (NOT C++) converter.
>
>    ii) FOR_C may choke on many of the non-standard F77 extensions used in
> your code.
>
> -- mecej4

What about the quality of the converted code? Can you read it? Can you 
maintain it? Or is it guacamole?

On Jun 25, 6:03=A0pm, Lynn McGuire <l...@winsim.com> wrote:
> >> My long term goal is to convert our F77 code to C++ using FOR_C.
> >> We may be trying this later this year when all of our Hollerith
> >> code is gone.
> > A couple of points to quote in that regard:
>
> > =A0 =A0 =A0i) Cobalt-Blue's FOR_C is an F77 to C (NOT C++) converter.
>
> Yes. =A0But converting C code to C++ code is fairly easy. =A0I've done
> it several times now. =A0However, converting char * strings to STL
> strings is non-trivial but that can be done later.
>
> > =A0 =A0 =A0ii) FOR_C may choke on many of the non-standard F77 extensio=
ns used in
> > your code.
>
> Nope. =A0FOR_C understands the vax structure, union, map and record
> keywords. =A0That is the only extension that we are currently using.
>
> Thanks,
> Lynn

Elsewhere you discuss a custom memory allocator where
you need to use EQUIVALENCE in a nonstandard way.  I
suspect you have many more extensions than you can
easily enumerate here.

Given that you appear to have problems porting Fortran
from Watcom to another compiler, I further suspect you'll
have problems with a fortran to c++ conversion.

--
steve

On 6/25/2010 8:16 PM, e p chandler wrote:
>
> "mecej4" <mecej4.nyetspam@operamail.com> wrote in message
> news:i03iq8$har$1@news.eternal-september.org...
>> Lynn McGuire wrote:
>>
>> <...>
>>> My long term goal is to convert our F77 code to C++ using FOR_C.
>>> We may be trying this later this year when all of our Hollerith
>>> code is gone.
>> A couple of points to quote in that regard:
>>
>> i) Cobalt-Blue's FOR_C is an F77 to C (NOT C++) converter.
>>
>> ii) FOR_C may choke on many of the non-standard F77 extensions used in
>> your code.
>>
>> -- mecej4
>
> What about the quality of the converted code? Can you read it? Can you
> maintain it? Or is it guacamole?
>
>

It is many years since I last tried FOR-C. The impression that I 
obtained was that the C produced was more readable and maintainable than 
the output of AT&T f2c; the latter was more fit to be used as a 
pre-processor prior to calling a C compiler.

-- mecej4

Lynn McGuire wrote:
>>> had one of my guys add an isothermal flash cache to our general
>>> flash. ...
>>
>> In a quick moment before heading to fields...
>>
>> I have no clue what you just said???
> 
....

> So anyway, we save the results of the calculations now.  If the
> flowsheet wants to make the same exact calculation again, we already
> have it saved.   Apparently saves a lot of time !
....

Too much wheat chaff yesterday, I suppose... :)

It dawned on me during the day what you meant; I initially read the 
"flash" as memory, not in the thermodynamic sense and that sent me off 
on a tangent...

On a side note, harvest '10 is over for us...finished not terribly late 
last night; now let it rain... :)

Very sad note; a couple of outstanding young men (college kids working 
summer) were killed in an grain elevator mishap day before yesterday 
when two of the silos failed and buried them while unloading a semi at 
an outside dump pit in Russell, KS.  It was a structural failure, not a 
grain dust explosion.  Russell is in north central KS, roughly 200 miles 
NE from us.

--

> Elsewhere you discuss a custom memory allocator where
> you need to use EQUIVALENCE in a nonstandard way.  I
> suspect you have many more extensions than you can
> easily enumerate here.

I am thinking about moving our variant data type from our structure to
several equivalanced arrays.  But that was so I could try the ftn95
compiler.  I just found out that the absoft compiler supports structure.

> Given that you appear to have problems porting Fortran
> from Watcom to another compiler, I further suspect you'll
> have problems with a fortran to c++ conversion.

Me too.  We use the /save feature of the watcom compiler, I keep on
forgetting that is an extension.  It does save and zero init automatically
also.  I need to get us off this feature, possibly by initializing all of our
local variables.

Thanks,
Lynn

> It is many years since I last tried FOR-C. The impression that I obtained was that the C produced was more readable and 
> maintainable than the output of AT&T f2c; the latter was more fit to be used as a pre-processor prior to calling a C compiler.

Thanks for the analysis of for_c.  I had a friend take a 100,000 line
f77 app to c with it several years ago.  He was porting to a Fujitsu
unix machine that only had a c compiler.  He thought for_c was OK
also, not great.  But they stayed with fortran for the main lanaguage of
their app and just reran for_c when necessary.

Thanks,
Lynn

> Given that you appear to have problems porting Fortran
> from Watcom to another compiler, I further suspect you'll
> have problems with a fortran to c++ conversion.

BTW, I should mention that our code worked fine on the Vax VMS, HP UX
and Sun Workstations using their native fortran 77 and c compilers.

Thanks,
Lynn

On 6/26/2010 10:32 AM, Lynn McGuire wrote:
>> Elsewhere you discuss a custom memory allocator where
>> you need to use EQUIVALENCE in a nonstandard way.  I
>> suspect you have many more extensions than you can
>> easily enumerate here.
>
> I am thinking about moving our variant data type from our structure to
> several equivalanced arrays.  But that was so I could try the ftn95
> compiler.  I just found out that the absoft compiler supports structure.

While I know that Absoft has (or had, my version is older) some 
extensions that Intel doesn't, I found that it lacked too many that 
Intel had that I used widely.  I've since decreased my use of extensions 
dramatically.  Reading this thread almost makes me want to jump in and 
help fix this code set.
snip
> Thanks,
> Lynn
>
>

> 1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf .

Awesome article, interesting conclusion:
"As will be obvious from the above, there is no natural choice of language for
the scientific user. The growing trend towards hybrid systems seems
essentially healthy, although it places greater demands for multi-linguality
on programmers. This should not be considered a bad thing. Furthermore,
the importance of the safe(r) subset should not be under-estimated. Use of
this concept can reduce maintenance costs and improve reliability
significantly. If C is to be used, it should be written compatibly with C++.
Fortran 90 features should be used with great care and there may be a
better alternative in C++."

The author states that moving F77 code to F90 may be as difficult as moving
F77 code to C++.

Also, a great list of rules for fortran of which we only violate half of them. But
then again, some of our code dates back to 1965.

Thanks,
Lynn

Lynn McGuire wrote:
>> 1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf .
> 
....

> The author states that moving F77 code to F90 may be as difficult as moving
> F77 code to C++.

Hmmm....that seems a stretch given how little actual F77 was removed 
from F90/95 (and that afaik, no vendors removed F77 features from 
compilers when adding F90+).  Granted, that there is at least one that 
started life as F90+ only, but it's a minority afaik.

OTOH, there isn't a line of F90/95 that is C++ if only lacking the 
trailing ; . :)

> Also, a great list of rules for fortran of which we only violate half of them. But
> then again, some of our code dates back to 1965.

Indeed, style has changed drastically and 1965 code predates F77 by 
enough that many of the common features that were later standardized 
either in the syntax of a particular compiler or in a near relative 
weren't even extensions at that point.

I'm not going to get into the religious debate over languages other than 
C++ is not on my personal list of choices as noted earlier... :)

--

Lynn McGuire wrote:
>> 1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf .

> Awesome article, interesting conclusion:
> "As will be obvious from the above, there is no natural choice of language for
> the scientific user.

That's definitely the case. I think it is at the end a question of
personal taste, availability of people (of the relevant field) which are
familiar with the language, whether certain language features (or their
lack of) make it easier or harder to implement the concrete project, the
language of other software being used/developed or the difficulty to
link/combine those. And the available infrastructure (e.g. existence of
sufficiently usable compilers, of free compilers, of already bought
compilers).

> Fortran 90 features should be used with great care and there may be a
> better alternative in C++."

The article has been written in 1992 where Fortran 90+ compilers were
essentially unavailable; thus the first statement makes sense. Nowadays,
I think one can safely use Fortran 95 and even many of the Fortran 2003
features.

> The author states that moving F77 code to F90 may be as difficult as moving
> F77 code to C++.

I do not agree with this. A standard conform Fortran 77 is also a valid
Fortran 90/95/2003/2008 program (ignoring some minor deleted items,
which compilers continue to support). Thus, if the program was a valid
Fortran 77 - it automatically is also a F90 program - that's definitely
easier than to convert to C/C++.

In general, it asks for less trouble in the short and medium term to
simply continue using Fortran and modernizing the program stepwise (e.g.
switching to dynamic allocation, if it makes sense). There exists also
some converters which make a F77 program more F90 looking.

Additionally, most compilers have a fairly good legacy support, thus the
chances are high that it will work unmodified (or only lightly modified)
even if the code is not fully standard conform. And - as Fortran is
backward compatible - most vendors ship a single compiler - independent
whether the user wants to use Fortran 77/90/95/2003/2008 features.

For the long term, I don't know whether converting to C/C++ is better or
not for your need. Since at your place, the number of C++ developers
seems to be larger, it might.

The problem with converting to C/C++: If the program is badly written
(with regards to modern software design) a simple conversion yields a
similarly badly written C/C++ program. (Plus the problems in semantics
and readability due to the conversion.) If you completely redesign the
program, you essentially start from scratch which will be a huge investment.

Tobias

In article 
<dqydnRQzSPW-tLvRnZ2dnUVZ_qCdnZ2d@posted.internetamerica>,
 "Lynn McGuire" <lmc@winsim.com> wrote:

> > Given that you appear to have problems porting Fortran
> > from Watcom to another compiler, I further suspect you'll
> > have problems with a fortran to c++ conversion.
> 
> BTW, I should mention that our code worked fine on the Vax VMS, HP UX
> and Sun Workstations using their native fortran 77 and c compilers.

Yes, but if your code were standard f77, it would be trivial to 
"port" your code to f90 and f95 compilers.  In most cases, the 
effort for that "port" would have simply been to recompile the 
existing code with the modern compiler.  If you further group your 
subroutines into modules, then you start to benefit from some of the 
modern features of the language with essentially no programming 
effort.

You should consider investing the effort to get rid of these 
nonstandard, and as you are finding nonportable, extensions.  It is 
much easier to do when you still have compilers that do support 
those extensions.  If you wait until there are no compilers that 
work with your code, when you can no longer examine intermediate 
results during the conversion process, it will be much more 
difficult.  And as a practical matter, it is always easier to port 
standard f77 code to newer versions of fortran than to some other 
language entirely; that has been one of the design considerations of 
the modern fortran standards.

As I said previously, the main benefit of having compilers support 
the nonstandard features of other compilers is to assist you in 
eliminating those features.  You have been using those extensions to 
delay that task, not to facilitate it.  Developing code in modern 
fortran is much better than with the older versions (including f77).  
With your current path, you are not benefiting from the newer 
language features.

$.02 -Ron Shepard

In article 
<KLqdnZTBFcS-zbvRnZ2dnUVZ_gWdnZ2d@posted.internetamerica>,
 "Lynn McGuire" <lmc@winsim.com> wrote:

> > 1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf .
> 
> Awesome article, 

From almost 20 years ago.  Since then there has been much progress 
in fortran.  Also, the enthusiasm for c++ in the late 80's and early 
90's has waned.  That was also at the end of the decade of the 80's 
when the standards committee drug its feet and delayed the approval 
of any new features in fortran, even the trivial ones which had been 
accepted as near universal extensions (such as the mil-std bit 
operators, do-enddo, implicit none, and so on).  In 1992, few people 
had practical experience with the new f90 features, and some of the 
important features (such as allocatable arrays) still had several 
shortcomings (could not be dummy arguments, could not be used in 
derived types, etc.).

> interesting conclusion:
> "As will be obvious from the above, there is no natural choice of language 
> for
> the scientific user. The growing trend towards hybrid systems seems
> essentially healthy, although it places greater demands for multi-linguality
> on programmers. 

Newer versions of fortran support interoperability with C in a 
direct way.

> This should not be considered a bad thing. Furthermore,
> the importance of the safe(r) subset should not be under-estimated. Use of
> this concept can reduce maintenance costs and improve reliability
> significantly. If C is to be used, it should be written compatibly with C++.

In hindsight, this last part of the sentence should be essentially 
reversed.  Some effort programming within C++ needs to be directed 
toward compatibility with C.  The general feeling in the late 80's 
was that C++ would replace C entirely.  That did not happen, and it 
is clear now that it is not going to happen.

> Fortran 90 features should be used with great care and there may be a
> better alternative in C++."

Do you think this might have changed in the past 20 years?  Now, the 
situation might even be reversed, where some tasks are easier, 
clearer, and more efficient, in fortran than in C++.

> 
> The author states that moving F77 code to F90 may be as difficult as moving
> F77 code to C++.

But we know that is simply not true.  Standard f77 is trivial to 
"port" to newer versions of fortran.

> Also, a great list of rules for fortran of which we only violate half of 
> them. But
> then again, some of our code dates back to 1965.

Yes, we've all been there.  Even now, if you look at a lot of netlib 
code, for example, you see programming style dating back to the 
60's.  Usually it is trivial to update.  That is one of the features 
of modern fortran.

$.02 -Ron Shepard

Lynn McGuire <lmc@winsim.com> wrote:

> > 1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf .

> The author states that moving F77 code to F90 may be as difficult as moving
> F77 code to C++.

I was curious what in the world would justify such a claim, so I read
the paper. I was ecpecting to find that it was talking about "f77" code
with loads of extensions or some such thing. Instead,

No, the paper doesn't actually say that. The closest thing I could find
sounds perhaps slightly simillar, but has a major extra bit that you
omitted. That extra bit is the entire reason for the claim, not just a
detail. In particular, the author says

  "The step from Fortran 77 to Fortran 90 is arguably therefore as large
as the step from Fortran 77 to C if the new features are to be used."

Note the "if the new features are to be used" bit. The step from f77 to
f90 is zero if you just want to take existing standard f77 code, which
is also already standard f90 code.

Reading in a bit more detail, it appears that this extra bit is based on
the author's belief that "the new features largely involve throwing away
most of the Fortran 77 features". Further reading reveals that the
author basically appears to have no idea what f90 is. I see no evidence
in the paper that he actually studied the language with any care. All of
his descriptions seem very broad brush, much like the above quote,
without even a hint of what specifics he might be alluding to. He
obviously would never have used an f90 compiler (insomuch as he alludes
to the f90 standard not haveing yet been completed when he wrote the
paper).

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Tobias Burnus <burnus@net-b.de> wrote:
(snip, someone wrote)
 
>> The author states that moving F77 code to F90 may be as 
>> difficult as moving F77 code to C++.
 
> I do not agree with this. A standard conform Fortran 77 is also a valid
> Fortran 90/95/2003/2008 program (ignoring some minor deleted items,
> which compilers continue to support). Thus, if the program was a valid
> Fortran 77 - it automatically is also a F90 program - that's definitely
> easier than to convert to C/C++.

It depends on what you mean by Fortran 90.  Yes it is valid Fortran 90
code but, for example, if it uses the Fortran 66 style allocation 
using large array in COMMON and EQUIVALENCE then one might say
that conversion to Fortran 90 includes conversion to real ALLOCATABLE
arrays.  For computation bound programs that don't do much I/O,
the conversion to C or C++ might not be so bad.  I/O is fairly
straightforward, but tedious to convert.  
 
> In general, it asks for less trouble in the short and medium term to
> simply continue using Fortran and modernizing the program stepwise (e.g.
> switching to dynamic allocation, if it makes sense). There exists also
> some converters which make a F77 program more F90 looking.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Tobias Burnus <burnus@net-b.de> wrote:
> (snip, someone wrote)
>  
> >> The author states that moving F77 code to F90 may be as 
> >> difficult as moving F77 code to C++.
>  
> > I do not agree with this. A standard conform Fortran 77 is also a valid
> > Fortran 90/95/2003/2008 program

> It depends on what you mean by Fortran 90. 

Not if you mean anything sensible. It is standard f90, which is what one
should mean by f90. Other changes, such as the ones you mentioned do not
constitute "moving f77 code to f90". Yes, one can misuse terminology all
you want. You can refer to such changes as "mowing the lawn" (which I
ought to go do instead of posting here) if you want to use that as your
terminology, but that doesn't make it correct. It just miscommunicates.

You are talking about making style changes among the choices available
within f90. That might or might not be a reasonable thing to do in any
particular context, but if you use terminology that describes that as
"moving f77 code to f90" you are likely to confuse yourself. Worse, even
if you know what you are talking about, other people will *NOT*. I
absolutely guarantee it.

Heck, they probably won't even know what you mean if you add the
appropriate qualifiers. Qualifiers like that tend to get dropped along
the way, even when they are central to the point. That's what happened
in Lynn's quote of the paper in question, for example. The paper
basically said that they thought the new features of f90 required
throwing out most of f77 and therefore in order to make use of those new
features of f90, you had to redo most of the f77 code. The bit about
needing to throw out most of f77 is a very questionable judgement (and
appears to be based on the author's poor understanding of f90 as far as
I can tell). But even if it were true, it is a critical qualifier to the
author's claim. Without it, the meaning of the claim is completely
different. Nonetheless, it got dropped in quotation, with consequent
change of meaning.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Lynn McGuire wrote:
>> 1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf .
> 
....

> The author states that moving F77 code to F90 may be as difficult as moving
> F77 code to C++.
....

In addition to the note Richard M has made regarding the full quote, and 
other comments I just add one...

The difficulties you've experienced moving from Watcom/OpenWatcom F77 to 
the IVF F95+ compiler aren't the language issues of F95 vis a vis F77 at 
all.  IVF is one currently supported compiler that does (and will surely 
continue to) support the VMS FORTRAN STRUCTURE your code uses so even 
that extension isn't the issue.

The issue is, as mentioned above, the reliance upon the peculiar feature 
of some compilers/OS'es to initialize all memory to zero or the Watcom 
/SAVE switch which has more widespread application than does, 
apparently, the same option(s) under IVF.

I fail to see how moving to C/C++/whatever will resolve this issue so it 
seems to me that moving to another language is a red-herring in the mix.

Eventually the deficient code is going to have to be fixed and it would 
seem more cost-effective to concentrate on that rather than move to 
another language and still have the problem to deal with.

As another poster noted, it's quite simple to take advantage of features 
of F95 in a progressive step and would seem (at least to me) that much 
of the code in Fortran likely gets little modification as being numeric 
routines of long-standing.  If so, it would seem it would follow that 
once the locations needing initialization are found and fixed it would 
again be essentially static but that as areas are identified for work 
they could at that time be placed in modules and those features that are 
useful incorporated as makes sense at the time.

$0.02, etc., etc., etc., ...

just an ol' wheat farmer so what do I know???  :)  -dpb

--

> The issue is, as mentioned above, the reliance upon the peculiar feature of some compilers/OS'es to initialize all memory to zero 
> or the Watcom /SAVE switch which has more widespread application than does, apparently, the same option(s) under IVF.

Hmmm.  It wasnt so peculiar back in the 1970s when we were supporting
ten different environments simultaenously.  Univac 1108, CDC cyber 6600
and 7600, PrimeOS, IBM 370 (that was the worst !), etc...

> I fail to see how moving to C/C++/whatever will resolve this issue so it seems to me that moving to another language is a 
> red-herring in the mix.

Yes, it is.  Our move to C++ is too soon to be planned at this time other
than generalities.  This group did a great job in helping me to figure out
what our next step needs to be after the Hollerith conversion project is
finished (that project is in year two !).  Just like our "implicit none" project
took a couple of years to implement.

But I do see C++ as necessary for us to remain competitive in the future.
Just as a matter of mention, the Apple iPhone/iPad only allow one to build
apps with Objective C (preferred), C, C++, and Java.  No Fortran
compilers are supported that I know of.   Not that we have a port planned
there but I am certainly thinking about it as the mobile market seems to be
exploding right now.  We dont currently have a MacOS version but several
customers are running our software there via Parallels, etc.

> Eventually the deficient code is going to have to be fixed and it would seem more cost-effective to concentrate on that rather 
> than move to another language and still have the problem to deal with.

Yes, the /save issue will need to be fixed before any compiler change.
I was thinking that another Fortran compiler might do a better job about
telling me which is initialized and which is not (an option that you mentioned
to me that I had not considered).  But, OW F77 should be workable in
this respect also for now even though it only does static analysis.

> just an ol' wheat farmer so what do I know???  :)  -dpb

<g> I've known quite few smart wheat farmers here in Texas over the years.
I just got into crisis mode myself as I have been working on making our
MS Excel interface interactive for our users.  We've been using DDE code
for dumping data into Excel for the past 18 years.  I just found out that the
DDE interface in Excel is not re-entrant so I get the "pleasure" of converting
our interface code into OLE automation.  And with a target ship date of
July 15 - not gonna happen !

Thanks,
Lynn

dpb <none@non.net> wrote:
(snip)
 
> The issue is, as mentioned above, the reliance upon the peculiar feature 
> of some compilers/OS'es to initialize all memory to zero or the Watcom 
> /SAVE switch which has more widespread application than does, 
> apparently, the same option(s) under IVF.
 
> I fail to see how moving to C/C++/whatever will resolve this issue so it 
> seems to me that moving to another language is a red-herring in the mix.

Most likely it won't, but do note that C (and C++) require static
variables not otherwise initialized to be initialized to zero.

That isn't the main reason to do the translation, but it is
part of the standard.

-- glen

"Lynn McGuire" <lmc@winsim.com> wrote in message 
news:5MGdnQ08UYC_DLvRnZ2dnUVZ_sqdnZ2d@posted.internetamerica...
>> The issue is, as mentioned above, the reliance upon the peculiar feature 
>> of some compilers/OS'es to initialize all memory to zero or the Watcom 
>> /SAVE switch which has more widespread application than does, apparently, 
>> the same option(s) under IVF.
>
> Hmmm.  It wasnt so peculiar back in the 1970s when we were supporting
> ten different environments simultaenously.  Univac 1108, CDC cyber 6600
> and 7600, PrimeOS, IBM 370 (that was the worst !), etc...
>
>> I fail to see how moving to C/C++/whatever will resolve this issue so it 
>> seems to me that moving to another language is a red-herring in the mix.
>
> Yes, it is.  Our move to C++ is too soon to be planned at this time other
> than generalities.  This group did a great job in helping me to figure out
> what our next step needs to be after the Hollerith conversion project is
> finished (that project is in year two !).  Just like our "implicit none" 
> project
> took a couple of years to implement.
>
> But I do see C++ as necessary for us to remain competitive in the future.
> Just as a matter of mention, the Apple iPhone/iPad only allow one to build
> apps with Objective C (preferred), C, C++, and Java.  No Fortran
> compilers are supported that I know of.   Not that we have a port planned
> there but I am certainly thinking about it as the mobile market seems to 
> be
> exploding right now.  We dont currently have a MacOS version but several
> customers are running our software there via Parallels, etc.
>
>> Eventually the deficient code is going to have to be fixed and it would 
>> seem more cost-effective to concentrate on that rather than move to 
>> another language and still have the problem to deal with.
>
> Yes, the /save issue will need to be fixed before any compiler change.
> I was thinking that another Fortran compiler might do a better job about
> telling me which is initialized and which is not (an option that you 
> mentioned
> to me that I had not considered).  But, OW F77 should be workable in
> this respect also for now even though it only does static analysis.
>
>> just an ol' wheat farmer so what do I know???  :)  -dpb
>
> <g> I've known quite few smart wheat farmers here in Texas over the years.
> I just got into crisis mode myself as I have been working on making our
> MS Excel interface interactive for our users.  We've been using DDE code
> for dumping data into Excel for the past 18 years.  I just found out that 
> the
> DDE interface in Excel is not re-entrant so I get the "pleasure" of 
> converting
> our interface code into OLE automation.  And with a target ship date of
> July 15 - not gonna happen !
>
> Thanks,
> Lynn

Sort of OT, but if you do use office automation, dumping data into Excel is 
much easier. Using VBA, sucking data into Excel is super easy. Pushing data 
in from another Office component or even classic VB or a dot Net language is 
not too bad - once you can deal with the object model. It's an improvement 
over DDE just as VBA is a vast improvement over Excel Macros in version 4.0 
(XLM).

Likewise, thinking about actually using the features of Fortran 90 looks 
overwhelming, but you may find that Fortran 95/2003 or whatever does 
actually simplify things considerably in the re-engineering process.

I'm probably thinking of someone else's code, but just replacing home grown 
routines for dynamic memory allocation with standard features of the 
language could cut down the actual work considerably. I predict that Fortran 
9x will be less prone to memory leaks and will give you better run-time 
diagnostics than C++.

As for your /SAVE and zero initialization issues, I do think that existing 
compilers like g95 and gfortran and Silverfrost do give you enough 
diagnostics to find the actual variables involved.

Elliot