experchange > fortran

Lynn McGuire (03-04-20, 11:39 PM)
"With A Little Help From My Friends"

"I spent last week at my first Fortran Standards Committee meeting. It
was a pretty interesting experience. Everyone there was brilliant, and
interested in trying to do a good job improving the language. And yet,
it was still somehow very disfunctional."

Yup, Fortran is dysfunctional nowadays. And I doubt that is going to
change, the roots are just too old.

Lynn
Gary Scott (03-05-20, 12:56 AM)
On 3/4/2020 3:39 PM, Lynn McGuire wrote:
> "With A Little Help From My Friends"
> "I spent last week at my first Fortran Standards Committee meeting. It
> was a pretty interesting experience. Everyone there was brilliant, and
> interested in trying to do a good job improving the language. And yet,
> it was still somehow very disfunctional."
> Yup, Fortran is dysfunctional nowadays.  And I doubt that is going to
> change, the roots are just too old.
> Lynn

Don't know about the meeting, but Fortran has dramatically improved.
I'm fairly happy with it other than needing a well designed bit string
data type and perhaps decimal or maybe really-really-big-integer math
support.
Steve Lionel (03-05-20, 03:30 AM)
On 3/4/2020 4:39 PM, Lynn McGuire wrote:
> "With A Little Help From My Friends"
> "I spent last week at my first Fortran Standards Committee meeting. It
> was a pretty interesting experience. Everyone there was brilliant, and
> interested in trying to do a good job improving the language. And yet,
> it was still somehow very disfunctional."
> Yup, Fortran is dysfunctional nowadays.  And I doubt that is going to
> change, the roots are just too old.


I disagree with that premise and with the observation. In fact a lot has
changed over the past couple of years, with significantly increased
participation of the user community and a streamlined process that
should get new revisions published faster. We're almost done with the
technical content of Fortran 202X.

It's true that not everyone gets their way, but my experience is that we
have made excellent progress. I am also delighted to see so many new
(and younger) faces at the meetings.
robin.vowels (03-05-20, 04:14 AM)
On Thursday, March 5, 2020 at 9:56:39 AM UTC+11, Gary Scott wrote:

> Don't know about the meeting, but Fortran has dramatically improved.
> I'm fairly happy with it other than needing a well designed bit string
> data type and perhaps decimal or maybe really-really-big-integer math
> support.


Bit strings and decimal data type have been available in PL/I since 1966.

IBM's PL/I currently offers decimal data to 31 digits
(both integer and fixed-point non-integer)

and 64-bit integers.

Decimal float has been available in the language since 1966 also,
though not every compiler provided decimal hardware.

With IEEE decimal floating-point available, IBM's compilers
use that hardware.
Gary Scott (03-05-20, 04:29 AM)
On 3/4/2020 8:14 PM, robin.vowels wrote:
> On Thursday, March 5, 2020 at 9:56:39 AM UTC+11, Gary Scott wrote:
> Bit strings and decimal data type have been available in PL/I since 1966.
> IBM's PL/I currently offers decimal data to 31 digits
> (both integer and fixed-point non-integer)
> and 64-bit integers.
> Decimal float has been available in the language since 1966 also,
> though not every compiler provided decimal hardware.
> With IEEE decimal floating-point available, IBM's compilers
> use that hardware.

:) I could have predicted this...but yes, I used PL/I on our mainframes
back 3 decades or so ago.
Lynn McGuire (03-05-20, 05:05 AM)
On 3/4/2020 4:56 PM, Gary Scott wrote:
> On 3/4/2020 3:39 PM, Lynn McGuire wrote:
> Don't know about the meeting, but Fortran has dramatically improved. I'm
> fairly happy with it other than needing a well designed bit string data
> type and perhaps decimal or maybe really-really-big-integer math support.


Fortran has improved at the expense of backwards compatibility. My
750,000 line software requires zero initialization and autosave to run.
Works great with the old Unix F77 compiler and the Open Watcom F77
compiler. Does not work with any of the F90+ compilers that I have
tried. We are going to try GFortran again this year using the Simply
Fortran IDE now that they support multiple targets.


Sigh, here come the flames.

Lynn
steve kargl (03-05-20, 05:36 AM)
Lynn McGuire wrote:

> On 3/4/2020 4:56 PM, Gary Scott wrote:
> Fortran has improved at the expense of backwards compatibility. My
> 750,000 line software requires zero initialization and autosave to run.


This suggests that your code does not conform to the Fortran 77 standard.
Perhaps, reviewing Fortran 77, section 2.11, might help with gaining an
understanding of your problem.

> Works great with the old Unix F77 compiler and the Open Watcom F77
> compiler.


Of course, it depends on processor dependent behavior

> Does not work with any of the F90+ compilers that I have
> tried. We are going to try GFortran again this year using the Simply
> Fortran IDE now that they support multiple targets.
>
> Sigh, here come the flames.


No flames. Just the reality. You have been posting laments about
your inability to fix your code here for at least a decade. If you
are keen on getting your code to run to exploit modern hardware,
it may behoove you to hire a consultant.
Lynn McGuire (03-05-20, 07:06 AM)
On 3/4/2020 9:36 PM, steve kargl wrote:
> Lynn McGuire wrote:
> This suggests that your code does not conform to the Fortran 77 standard.
> Perhaps, reviewing Fortran 77, section 2.11, might help with gaining an
> understanding of your problem.
> Of course, it depends on processor dependent behavior
> No flames. Just the reality. You have been posting laments about
> your inability to fix your code here for at least a decade. If you
> are keen on getting your code to run to exploit modern hardware,
> it may behoove you to hire a consultant.


Sorry but our software went commercial back in 1969 on the UCC
(University Computing Center) time sharing service on their 64K word
Univac 1108. Fortran IV (66) on a good day with 6 bit bytes (no lower
case) and 36 bit words. Since then we have ported the software to 12 ?
13 ? 14 ? platforms. I started working with the software in 1975.
Never a problem with auto initialization or auto save in all that time
until we tried porting to the F90+ compilers.

Lynn
steve kargl (03-05-20, 07:51 AM)
Lynn McGuire wrote:

> On 3/4/2020 9:36 PM, steve kargl wrote:
> Sorry but our software went commercial back in 1969 on the UCC
> (University Computing Center) time sharing service on their 64K word
> Univac 1108. Fortran IV (66) on a good day with 6 bit bytes (no lower
> case) and 36 bit words. Since then we have ported the software to 12 ?
> 13 ? 14 ? platforms. I started working with the software in 1975.
> Never a problem with auto initialization or auto save in all that time
> until we tried porting to the F90+ compilers.


Not sure what your sorry about. Does not matter what you did in
1969 or in the 12 or 13 ports you've done. If the code has always
required auto initialization and auto save, then it has never conformed
with any Fortran standard, include Fortran 66.

Yes, I know, your software is a commercial product. This is precisely
why I suggested you hire a consultant who is capable of fixing your
nonconforming Fortran code. Reading your complaints that no
F90+ compiler can do anything useful with code is getting tiresome.
Louis Krupp (03-05-20, 08:26 AM)
On Wed, 4 Mar 2020 23:06:53 -0600, Lynn McGuire
<lynnmcguire5> wrote:

>On 3/4/2020 9:36 PM, steve kargl wrote:
>Sorry but our software went commercial back in 1969 on the UCC
>(University Computing Center) time sharing service on their 64K word
>Univac 1108. Fortran IV (66) on a good day with 6 bit bytes (no lower
>case) and 36 bit words. Since then we have ported the software to 12 ?
>13 ? 14 ? platforms. I started working with the software in 1975.
>Never a problem with auto initialization or auto save in all that time
>until we tried porting to the F90+ compilers.


I'll second the consultant suggestion. Your list of requirements could
include:

1. Familiarity with modern Fortran and its antecedents.
2. Ability to modify code while resisting the urge to rewrite stuff
without a really good reason.
3. Tolerance for pain.

Louis
spectrum (03-05-20, 01:39 PM)
On Thursday, March 5, 2020 at 12:05:34 PM UTC+9, Lynn McGuire wrote:

> Fortran has improved at the expense of backwards compatibility. My
> 750,000 line software requires zero initialization and autosave to run.
> Works great with the old Unix F77 compiler and the Open Watcom F77
> compiler. Does not work with any of the F90+ compilers that I have
> tried. We are going to try GFortran again this year (...snip...)


As for zero initialization and autosave, isn't an option like "-finit-local-zero" and
"-fno-automatic" useful for that purpose?
I guess similar options are available for other compiles (but not checked myself...)

From the man page of gfortran-9 ("man gfortran-9" on the terminal of MacOS10.11):

-finit-local-zero
-finit-derived
-finit-integer=n
-finit-real=<zero|inf|-inf|nan|snan>
-finit-logical=<true|false>
-finit-character=n
The -finit-local-zero option instructs the compiler to initialize
local "INTEGER", "REAL", and "COMPLEX" variables to zero,
"LOGICAL" variables to false, and "CHARACTER" variables to a
string of null bytes. Finer-grained initialization options are
provided by the -finit-integer=n,
-finit-real=<zero|inf|-inf|nan|snan> (which also initializes the
real and imaginary parts of local "COMPLEX" variables),
-finit-logical=<true|false>, and -finit-character=n (where n is
an ASCII character value) options.
...

-fno-automatic
Treat each program unit (except those marked as RECURSIVE) as if
the "SAVE" statement were specified for every local variable and
array referenced in it. Does not affect common blocks. (Some
Fortran compilers provide this option under the name -static or
-save.) The default, which is -fautomatic, uses the stack for
local variables smaller than the value given by
-fmax-stack-var-size. Use the option -frecursive to use no
static memory.
robin.vowels (03-05-20, 03:26 PM)
On Thursday, March 5, 2020 at 2:05:34 PM UTC+11, Lynn McGuire wrote:
> On 3/4/2020 4:56 PM, Gary Scott wrote:
> Fortran has improved at the expense of backwards compatibility. My
> 750,000 line software requires zero initialization and autosave to run.


Zero initialization was never standard Fortran ;
it was a particular manufacturer's extension.

> Works great with the old Unix F77 compiler and the Open Watcom F77
> compiler.


Those are 30+ year-old compilers and are long out-of-date.

> Does not work with any of the F90+ compilers that I have
> tried.


And probably never will.
gah4 (03-05-20, 04:16 PM)
On Thursday, March 5, 2020 at 5:26:05 AM UTC-8, robin...@gmail.com wrote:

(snip)

> Zero initialization was never standard Fortran ;
> it was a particular manufacturer's extension.


Or an accident.

For many years, you got whatever was leftover in memory, either
before the program was loaded, or was filled in by the linkage
editor. (For OS/360, it is a combination of the two.)

At some point, it was decided that was a security risk, and
memory had to be cleared. Whatever the linkage editor filled
in was yours, and not someone else's, so that was fine.

I do remember a system in the late OS/360 days that initialized
with X'81', both in the linkage editor and before program fetch.
That worked pretty well for Fortran (static data).

C guarantees static data is initialized to zero, but automatic
(stack) data gets whatever is there. This requirement leaks over
into other systems using, for example, the same linker.

Years ago (again, OS/360 days) I had a program that I suspected
was using either uninitialized data or data out of array bounds,
and I had WATFIV. WATFIV was one of the few compilers at the time
to check array bounds (not optional), and also check for uninitialized
data. Some runs with that, and some careful selection of input data
got that pretty well cleaned up.

What some people are saying to Lynn is that it is about time
to fix the program. If you set floating point data to SNaN, it
should be somewhat fast to find. Setting integers to X'81818181'
tends to cause some problems near the mistake, such that you
can find them. In addition, you might find other bugs that
were not previously known.
mecej4 (03-05-20, 05:46 PM)
On 3/4/2020 3:39 PM, Lynn McGuire wrote:
> Yup, Fortran is dysfunctional nowadays.  And I doubt that is going to
> change, the roots are just too old.


I can see a mountain a dozen miles away. Ten years ago, I asked it to
come to me, but it just stays there.

It's a dysfunctional mountain. And I doubt that is going to change, the
roots are just too old.

I hear that people go to the mountain, climb up and come back happier.
They must not be very smart, those people. A pity.

-- mecej4
Dick Hendrickson (03-05-20, 06:10 PM)
On 3/5/20 8:16 AM, gah4 wrote:
> On Thursday, March 5, 2020 at 5:26:05 AM UTC-8, robin...@gmail.com wrote:
> (snip)
> Or an accident.
> For many years, you got whatever was leftover in memory, either
> before the program was loaded, or was filled in by the linkage
> editor. (For OS/360, it is a combination of the two.)
> At some point, it was decided that was a security risk, and
> memory had to be cleared. Whatever the linkage editor filled
> in was yours, and not someone else's, so that was fine.

One operating system, on a machine with 10 characters per word, sprayed
memory with

10HURAHORSES*

Dick Hendrickson
[..]

Similar Threads