Fortran 90/95 compilers for Dos/Win16

[Lorenzo Lodi]

For a retrocomputing project I'd like to find a Fortran 90 or 95
compiler to be used under Dos or Windows 3.11. The idea is to compare
the performance on a 386-class computer from the early 1990s to a modern
one, and I'd be nice if I could use F90/95 instead of F77 (I still have
to write the programs I'm planning to test).
I know that Nag and Salford produced a Fortran 90 compiler for Dos, and
Salford also later released a Dos/Win16 version of its FTN95 compiler in
the mid 1990s. Anybody knows where I could find them? I searched the
internet far and wide but I couldn't find anything.

[Sjouke Burry]

Post by Lorenzo Lodi
For a retrocomputing project I'd like to find a Fortran 90 or 95
compiler to be used under Dos or Windows 3.11. The idea is to compare
the performance on a 386-class computer from the early 1990s to a modern
one, and I'd be nice if I could use F90/95 instead of F77 (I still have
to write the programs I'm planning to test).
I know that Nag and Salford produced a Fortran 90 compiler for Dos, and
Salford also later released a Dos/Win16 version of its FTN95 compiler in
the mid 1990s. Anybody knows where I could find them? I searched the
internet far and wide but I couldn't find anything.

Might check (older) watcom fortran.

[Lynn McGuire]

Post by Sjouke Burry

Post by Lorenzo Lodi
For a retrocomputing project I'd like to find a Fortran 90 or 95
compiler to be used under Dos or Windows 3.11. The idea is to compare
the performance on a 386-class computer from the early 1990s to a modern
one, and I'd be nice if I could use F90/95 instead of F77 (I still have
to write the programs I'm planning to test).
I know that Nag and Salford produced a Fortran 90 compiler for Dos, and
Salford also later released a Dos/Win16 version of its FTN95 compiler in
the mid 1990s. Anybody knows where I could find them? I searched the
internet far and wide but I couldn't find anything.

Might check (older) watcom fortran.

http://www.openwatcom.org/

Open Watcom F77 is a very extended F77 compiler. Many of the extensions
were for source code structure or line length. No integer*8 or defined
variables or interfaces.

Lynn

[gah4]

Post by Lorenzo Lodi
For a retrocomputing project I'd like to find a Fortran 90 or 95
compiler to be used under Dos or Windows 3.11. The idea is to compare
the performance on a 386-class computer from the early 1990s to a modern
one, and I'd be nice if I could use F90/95 instead of F77 (I still have
to write the programs I'm planning to test).
I know that Nag and Salford produced a Fortran 90 compiler for Dos, and
Salford also later released a Dos/Win16 version of its FTN95 compiler in
the mid 1990s. Anybody knows where I could find them? I searched the
internet far and wide but I couldn't find anything.

It depends some one what you are trying to compare.
The math processor was optional for the 386, so compilers could generate
either x87 code or software floating point. (You didn't say if you were
interested in floating point, though that is usual for Fortran.)

For some years, compilers would support various DOS extenders
to run 32 bit code under DOS. I believe some Fortran compilers
did that, and, though it would have been later, would still support
older versions of DOS.

Otherwise, FreeBSD was available in 1993 and ran well on 386 machines,
though by not much later, I usually had a 486 for it. I never had a Fortran compiler
on my FreeBSD machines, but there might have been one that could generate
code for one.

The 386 is the base of IA32, so many later systems are supposed to run on one,
at least with enough RAM.

[Lorenzo Lodi]

On 12/08/2021 00:19, gah4 wrote:
[...]

Post by gah4
It depends some one what you are trying to compare.
The math processor was optional for the 386, so compilers could generate
either x87 code or software floating point. (You didn't say if you were
interested in floating point, though that is usual for Fortran.)

Thank you all for the reply!
I'll give some more context. In 1993, when a way a young boy, my parents
bought their first computer, a rather bare-bone 386DX/40MB with 4MB of
ram and a 200MB hard disk (no mouse, no sound card). It was bought
mostly for accountancy tasks, but of course I used it for games
(although it obsolescing really fast) and it played a key role in
developing my interest in computers.
By the time I got to university and became acquainted with numerical
methods and Fortran I had already moved on to a newer system, so I never
did any programming on it.

Not long ago I decided to dig up the old dinosaur from the cellar and
give it a second breath of life. It needed some work (a huge cobweb had
shorted the motherboard, the cmos battery leaked, etc.) but it is now
not only as clean as a whistle but also upgraded with 8MB of ram, a
387/DX floating point unit, a second, larger hard disk, sound card and a
Gotek Floppy Emulator (to read USB pendrives as if they were floppies)
and is now perfectly working.


In a different project, I've been preparing for some time a series of
presentations on methods to solve (=find eigenvalues and eigenvectors)
the one-dimensional Schrodinger equation (quantum mechanics), from very
basic shooting approaches to more advanced ones. Now, on a modern
computer even the slowest-converging methods would probably give
accurate results in a few seconds, so the advantage of faster method
won't probably be very striking. Of course I could artificially slow
down the machine using utilities or emulators, or run the method
repeatedly as register how many passes it does in, say, 10 seconds, but
this seems the perfect occasion to put to good use my resurrected 386.
Also, I've always wondered how much scientific computing one could do on
personal computers in the 1980s and early 1990s.

So the primary purpose is to show pros and cons of various numerical
approaches to the 1D Schrodinger equation and, as a by product and a bit
of fun, to show benchmarks on my DOS 386 and my modern PC. For this
reason I need a programming language which is supported both on the old
and the new system, and Fortran seems to be a good choice (the other
possibility I considered is ANSI C).
Development will take place on the modern system with modern compilers
(gfortran and Intel) but enforcing strict adherence to the Fortran
standard supported by the old system (F77, F90 or F95 depending on what
I can find).

At the moment I found here
https://winworldpc.com/product/fortran-powerstation/1x
a copy of Microsoft FORTRAN Powerstation 1.0a for Dos and Windows 3.1
It fits on three 1.44MB floppies and takes, installed, about 4 MB or so.
It's a F77 compiler with a few F90-like extensions (free format, enddo,
cycle, exit) and it use a 32bit DOS extender. It works fine from the
preliminary tests I did, it makes use of the FPU if present otherwise
uses software emulation.

This is a good start, but if possible I'd prefer to have a compiler with
full F90 (or 95) support.

Post by gah4
For some years, compilers would support various DOS extenders
to run 32 bit code under DOS. I believe some Fortran compilers
did that, and, though it would have been later, would still support
older versions of DOS.

You are right, ASAIK the last generation of DOS Fortran compilers (first
half of the 1990s) used 32bit Dos extenders and VxD drivers under
Windows 3.1 (https://en.wikipedia.org/wiki/VxD).
I've done a little more research (sometimes using the wayback machine to
see old versions of websites) and I can confirm the following DOS
Fortran compilers existed:

1. NAGware Fortran 90 v1 (released January 1992 -- the first F90 compiler)

2. NAGware Fortran 90 v2.1, v2.2, v2.11, v2.18 (released between 1993
and 1997 or so -- co-developed with Salford Software)

Nag released its NAGware Fortran 95 compiler in 1997 or 1998 but ASAIK
only for Linux (no Dos versions).

3. Salford FTN90 (possibly the same as NAGware v2.x)

4. Salford FTN95 (released in 1997 --- as far as I can tell the only F95
compiler for Dos)

5. Lahey Fortran 90 (LF90) v3.0 (released in 1996 as far as I can tell)

6. Lahey Fortran 90 (LF90) v4.0, v.4.5 (released in 1998; it should also
support DOS but it's mostly a Windows NT suite as far as I can tell)

Lahey released F95 compilers as Lahey/Fujitsu, but I don't think they
support Dos.


Other people have suggested the Open Watcom F77 (thanks!). The main
problem I see (apart from the old standard) is that it takes 66.4 MB
zipped (I'd have to break it up into 50 floppies to transfer it) and
148.9 MB unzipped, which is just HUGE for my 386 system and also suggest
its memory requirements would probably overwhelm my machine. Also, I'm
not sure I'd gain very much from the Microsoft F77 compiler I already
have and which takes only 4MB or so.
I could install it on the modern machine in Dosbox and then copy to the
old system only the executable, but I'd rather avoid this route if possible.

Thank you all for the help. I'll post any further developments.

[gah4]

On Thursday, August 12, 2021 at 4:16:13 AM UTC-7, Lorenzo Lodi wrote:

(snip)

Post by Lorenzo Lodi
Thank you all for the reply!
I'll give some more context. In 1993, when a way a young boy, my parents
bought their first computer, a rather bare-bone 386DX/40MB with 4MB of
ram and a 200MB hard disk (no mouse, no sound card). It was bought
mostly for accountancy tasks, but of course I used it for games
(although it obsolescing really fast) and it played a key role in
developing my interest in computers.
By the time I got to university and became acquainted with numerical
methods and Fortran I had already moved on to a newer system, so I never
did any programming on it.

(snip)

Post by Lorenzo Lodi
Also, I've always wondered how much scientific computing one could do on
personal computers in the 1980s and early 1990s.

OK, I was doing scientific computing on PCs from about 1987, starting
with a clone 286 machine with 287. First running DOS, but by early 1990
I was running OS/2 1.0 on it, with the Microsoft C compiler.

Not so much later, I had the Watcom C and Fortran compilers, though.
Even while using the MS compiler, I would use the Watcom linker, which
has a good overlay system. While I was running on OS/2, the programs
had to also run on DOS. I think I was up to 5MB by that time.

Not so much later, a 486 machine and OS/2 2.0 allowed for Ethernet
and TCP/IP, making the data transfer much easier.

Otherwise, there are Zip drives which are convenient for transferring larger files.
But I would go for Ethernet.

In any case, yes, you can do fine scientific computing on a 386/387 box.

[Robin Vowels]

Post by Lorenzo Lodi
[...]

Post by gah4
It depends some one what you are trying to compare.
The math processor was optional for the 386, so compilers could generate
either x87 code or software floating point. (You didn't say if you were
interested in floating point, though that is usual for Fortran.)

Thank you all for the reply!
I'll give some more context. In 1993, when a way a young boy, my parents
bought their first computer, a rather bare-bone 386DX/40MB with 4MB of
ram and a 200MB hard disk (no mouse, no sound card). It was bought
mostly for accountancy tasks, but of course I used it for games
(although it obsolescing really fast) and it played a key role in
developing my interest in computers.
By the time I got to university and became acquainted with numerical
methods and Fortran I had already moved on to a newer system, so I never
did any programming on it.
Not long ago I decided to dig up the old dinosaur from the cellar and
give it a second breath of life. It needed some work (a huge cobweb had
shorted the motherboard, the cmos battery leaked, etc.) but it is now
not only as clean as a whistle but also upgraded with 8MB of ram, a
387/DX floating point unit, a second, larger hard disk, sound card and a
Gotek Floppy Emulator (to read USB pendrives as if they were floppies)
and is now perfectly working.
In a different project, I've been preparing for some time a series of
presentations on methods to solve (=find eigenvalues and eigenvectors)
the one-dimensional Schrodinger equation (quantum mechanics), from very
basic shooting approaches to more advanced ones. Now, on a modern
computer even the slowest-converging methods would probably give
accurate results in a few seconds, so the advantage of faster method
won't probably be very striking. Of course I could artificially slow
down the machine using utilities or emulators, or run the method
repeatedly as register how many passes it does in, say, 10 seconds, but
this seems the perfect occasion to put to good use my resurrected 386.
Also, I've always wondered how much scientific computing one could do on
personal computers in the 1980s and early 1990s.
So the primary purpose is to show pros and cons of various numerical
approaches to the 1D Schrodinger equation and, as a by product and a bit
of fun, to show benchmarks on my DOS 386 and my modern PC. For this
reason I need a programming language which is supported both on the old
and the new system, and Fortran seems to be a good choice (the other
possibility I considered is ANSI C).
Development will take place on the modern system with modern compilers
(gfortran and Intel) but enforcing strict adherence to the Fortran
standard supported by the old system (F77, F90 or F95 depending on what
I can find).
At the moment I found here
https://winworldpc.com/product/fortran-powerstation/1x
a copy of Microsoft FORTRAN Powerstation 1.0a for Dos and Windows 3.1
It fits on three 1.44MB floppies and takes, installed, about 4 MB or so.
It's a F77 compiler with a few F90-like extensions (free format, enddo,
cycle, exit) and it use a 32bit DOS extender. It works fine from the
preliminary tests I did, it makes use of the FPU if present otherwise
uses software emulation.
This is a good start, but if possible I'd prefer to have a compiler with
full F90 (or 95) support.

Post by gah4
For some years, compilers would support various DOS extenders
to run 32 bit code under DOS. I believe some Fortran compilers
did that, and, though it would have been later, would still support
older versions of DOS.

You are right, ASAIK the last generation of DOS Fortran compilers (first
half of the 1990s) used 32bit Dos extenders and VxD drivers under
Windows 3.1 (https://en.wikipedia.org/wiki/VxD).
I've done a little more research (sometimes using the wayback machine to
see old versions of websites) and I can confirm the following DOS
1. NAGware Fortran 90 v1 (released January 1992 -- the first F90 compiler)

.
Salford Software produced the first Fortran 90 compiler for the PC.
It has an integrated screen graphics system.
.

Post by Lorenzo Lodi
2. NAGware Fortran 90 v2.1, v2.2, v2.11, v2.18 (released between 1993
and 1997 or so -- co-developed with Salford Software)
Nag released its NAGware Fortran 95 compiler in 1997 or 1998 but ASAIK
only for Linux (no Dos versions).
3. Salford FTN90 (possibly the same as NAGware v2.x)

.
See above.
.

Post by Lorenzo Lodi
4. Salford FTN95 (released in 1997 --- as far as I can tell the only F95
compiler for Dos)
5. Lahey Fortran 90 (LF90) v3.0 (released in 1996 as far as I can tell)
6. Lahey Fortran 90 (LF90) v4.0, v.4.5 (released in 1998; it should also
support DOS but it's mostly a Windows NT suite as far as I can tell)
Lahey released F95 compilers as Lahey/Fujitsu, but I don't think they
support Dos.
Other people have suggested the Open Watcom F77 (thanks!). The main
problem I see (apart from the old standard) is that it takes 66.4 MB
zipped (I'd have to break it up into 50 floppies to transfer it) and
148.9 MB unzipped, which is just HUGE for my 386 system and also suggest
its memory requirements would probably overwhelm my machine. Also, I'm
not sure I'd gain very much from the Microsoft F77 compiler I already
have and which takes only 4MB or so.
I could install it on the modern machine in Dosbox and then copy to the
old system only the executable, but I'd rather avoid this route if possible.
Thank you all for the help. I'll post any further developments.

[Lorenzo Lodi]

Post by Robin Vowels

Post by Lorenzo Lodi
1. NAGware Fortran 90 v1 (released January 1992 -- the first F90 compiler)

.
Salford Software produced the first Fortran 90 compiler for the PC.
It has an integrated screen graphics system.

Are you sure about that? Several online sources indicate that the first
F90 compiler was written by Malcolm Cohen at NAG. Nag has a page
detailing this history:
https://www.nag.com/content/personal-history-nag-fortran-compiler
https://www.nag.com/content/malcolm-cohen

Contrary to what I wrote in my previous post, it seems that this
compiler (NAG v1.0) was released in September 1991, not in January 1992.
If I understand correctly, it was in fact a Fortran-to-C translator, and
therefore relied on an external C compiler for the actual compilation stage.

BTW, there should be yet another F90 compiler targeting DOS, namely
Absoft (although according to this post
http://computer-programming-forum.com/49-fortran/369cc69b8980a4c0.htm
you had to provide the 32 bit DOS extender yourself).

Lorenzo

[Jos Bergervoet]

Post by Lorenzo Lodi

Post by Robin Vowels

Post by Lorenzo Lodi
1. NAGware Fortran 90 v1 (released January 1992 -- the first F90 compiler)

.
Salford Software produced the first Fortran 90 compiler for the PC.
It has an integrated screen graphics system.

Are you sure about that? Several online sources indicate that the first
F90 compiler was written by Malcolm Cohen at NAG. Nag has a page
https://www.nag.com/content/personal-history-nag-fortran-compiler
https://www.nag.com/content/malcolm-cohen
Contrary to what I wrote in my previous post, it seems that this
compiler (NAG v1.0) was released in September 1991, not in January 1992.
If I understand correctly, it was in fact a Fortran-to-C translator, and

Then also the Pacific Sierra f90 compiler should count. (I don't know
immediately what year it was from.) This was an f90 to f77 translator.

(Perhaps it did not fully support the f90 standard. At least it had
problems with complex double precision variables, since referencing
them as an array element in an f77 common block fails half the time..)

[Robin Vowels]

Then also the Pacific Sierra f90 compiler should count. (I don't know
immediately what year it was from.) This was an f90 to f77 translator.

.
It wasn't a compiler, just a language translator.
.

(Perhaps it did not fully support the f90 standard. At least it had
problems with complex double precision variables, since referencing
them as an array element in an f77 common block fails half the time..)

[Jos Bergervoet]

Post by Robin Vowels

Then also the Pacific Sierra f90 compiler should count. (I don't know
immediately what year it was from.) This was an f90 to f77 translator.

.
It wasn't a compiler, just a language translator.

And in tandem with g77 it translated to machine language. So that was
not the problem..

Post by Robin Vowels
.

(Perhaps it did not fully support the f90 standard. At least it had
problems with complex double precision variables, since referencing
them as an array element in an f77 common block fails half the time..)

This was at the time when the only other alternative for a free f90
compiler was the "F" compiler, which also did not support the full
f90 standard. And trying to writing code suitable for both of them
was a rather annoying puzzle.

(Why would one try to do that? Well, in those days we wanted to
increase the popularity of Fortran by showing that f90 gave rise to
much cleaner, and 3 times shorter, and easier to read code than e.g.
C would for the same problem. But then no-one on the internet would
do anything with it unless you could also give a free download link
for a compiler!)

[Robin Vowels]

Post by Jos Bergervoet

Post by Robin Vowels

Post by Jos Bergervoet
Then also the Pacific Sierra f90 compiler should count. (I don't know
immediately what year it was from.) This was an f90 to f77 translator.

.
It wasn't a compiler, just a language translator.

And in tandem with g77 it translated to machine language. So that was
not the problem..

Post by Robin Vowels
.

Post by Jos Bergervoet
(Perhaps it did not fully support the f90 standard. At least it had
problems with complex double precision variables, since referencing
them as an array element in an f77 common block fails half the time..)

This was at the time when the only other alternative for a free f90
compiler was the "F" compiler,

.
ELF90 was also available, so was Salford FTN90.

Post by Jos Bergervoet
which also did not support the full
f90 standard. And trying to writing code suitable for both of them
was a rather annoying puzzle.

F included the modern constructs, and it was easy to write
in modern Fortran. Source compiled in both F and F90 compilers.

Post by Jos Bergervoet
(Why would one try to do that? Well, in those days we wanted to
increase the popularity of Fortran by showing that f90 gave rise to
much cleaner, and 3 times shorter, and easier to read code than e.g.
C would for the same problem. But then no-one on the internet would
do anything with it unless you could also give a free download link
for a compiler!)

[gah4]

(snip)

Post by Jos Bergervoet
(Perhaps it did not fully support the f90 standard. At least it had
problems with complex double precision variables, since referencing
them as an array element in an f77 common block fails half the time..)

Referencing double precision variables failed half the time in F66 and F77 days,
until padding was allowed, on machines that required alignment. Well,
people learned how to get them aligned, but if you randomly add variables
to COMMON, it could easily happen.

Was F90 the one when padding was allowed?

I remember fix-up routines that would copy data to somewhere with
the right alignment, redo the operation, then copy back. Except that it
didn't work with imprecise interrupts.

[Jos Bergervoet]

Post by gah4
(snip)

Post by Jos Bergervoet
(Perhaps it did not fully support the f90 standard. At least it had
problems with complex double precision variables, since referencing
them as an array element in an f77 common block fails half the time..)

Referencing double precision variables failed half the time in F66 and F77 days,
until padding was allowed, on machines that required alignment. Well,
people learned how to get them aligned, but if you randomly add variables
to COMMON, it could easily happen.

The g77 compiler (invoked after the f90 to f77 translation) would
align all things on 8 Byte boundaries.

But the f90 pointers and offsets in array-slice descriptors had to
be implemented as integer index to arrays in a common block (an
array for each data type, all equivalenced to each other, and also
"abused" with out-of-bounds indexing to reach the addresses of all
variables declared in the code in the "normal" way.)

This all works well for the smaller data types, but for double
precision complex the array in the common block only has elements
with 16 Byte stride, whereas an arbitrary double precision complex
variable in the code can be at any 8 Byte boundary, so it has 50%
chance of *not* matching with an element of the array, which means
that it cannot be pointed at by a pointer in this (tricky) way.

Post by gah4
Was F90 the one when padding was allowed?

The problem here was that g77 had to be persuaded to put every
double precision complex variable on a 16 Byte boundary, which
it did not do by default (a special version of g77 might have
worked but then it no longer would have been a true f90 to f77
translator..)

Post by gah4
I remember fix-up routines that would copy data to somewhere with
the right alignment, redo the operation, then copy back. Except that it
didn't work with imprecise interrupts.

I had some email conversations with the developer of the translator
and it really was a pity that this little problem stood in the way
because for the rest the method worked fine, and even produced
fairly well readable f77 code. It also could work with f2c and
then effectively work as an f90 to C converter..

(Of course when f95 introduced more features, the whole translation
would have become much too difficult to do in this way. Also, f77
became obsolete at some point so translating to f77 lost its
value. It sure is anathema now!)

[gah4]

On Saturday, August 14, 2021 at 2:06:04 PM UTC-7, Jos Bergervoet wrote:

(snip)

Post by Jos Bergervoet
The g77 compiler (invoked after the f90 to f77 translation) would
align all things on 8 Byte boundaries.
But the f90 pointers and offsets in array-slice descriptors had to
be implemented as integer index to arrays in a common block (an
array for each data type, all equivalenced to each other, and also
"abused" with out-of-bounds indexing to reach the addresses of all
variables declared in the code in the "normal" way.)
This all works well for the smaller data types, but for double
precision complex the array in the common block only has elements
with 16 Byte stride, whereas an arbitrary double precision complex
variable in the code can be at any 8 Byte boundary, so it has 50%
chance of *not* matching with an element of the array, which means
that it cannot be pointed at by a pointer in this (tricky) way.

Post by gah4
Was F90 the one when padding was allowed?

The problem here was that g77 had to be persuaded to put every
double precision complex variable on a 16 Byte boundary, which
it did not do by default (a special version of g77 might have
worked but then it no longer would have been a true f90 to f77
translator..)

I was not so long ago working with Spice2g6. That is, the last of the
Spice (circuit simulation programs) in Fortran.

The distributed version uses default COMPLEX, but it seems
to be designed so that one can use other types. There are EQUIVALENCEd
arrays of integer, double precision, and complex type. It then computes
the index into the appropriate array, knowing the needed stride.
(It uses LOC() at various points to figure that out.)

In the case of COMPLEX*16 arrays, it will only index them on multiples
of 16 bytes. (I believe IBM S/370 and VAX were popular hosts, both
of which have COMPLEX*16 in their Fortran compilers.)

I suspect I am the first one to try to compile it in a long time, and
especially with gfortran. There are some subroutines that were
written in assembly for some previous systems, like one to copy
a large array from one place to another fast. There are also some
to work with character data in A8 format, stored in double precision
array elements. (All keywords only need to be specified to the
first 8 characters.)

[Lynn McGuire]

Post by gah4
(snip)

Post by Jos Bergervoet
The g77 compiler (invoked after the f90 to f77 translation) would
align all things on 8 Byte boundaries.
But the f90 pointers and offsets in array-slice descriptors had to
be implemented as integer index to arrays in a common block (an
array for each data type, all equivalenced to each other, and also
"abused" with out-of-bounds indexing to reach the addresses of all
variables declared in the code in the "normal" way.)
This all works well for the smaller data types, but for double
precision complex the array in the common block only has elements
with 16 Byte stride, whereas an arbitrary double precision complex
variable in the code can be at any 8 Byte boundary, so it has 50%
chance of *not* matching with an element of the array, which means
that it cannot be pointed at by a pointer in this (tricky) way.

Post by gah4
Was F90 the one when padding was allowed?

The problem here was that g77 had to be persuaded to put every
double precision complex variable on a 16 Byte boundary, which
it did not do by default (a special version of g77 might have
worked but then it no longer would have been a true f90 to f77
translator..)

I was not so long ago working with Spice2g6. That is, the last of the
Spice (circuit simulation programs) in Fortran.
The distributed version uses default COMPLEX, but it seems
to be designed so that one can use other types. There are EQUIVALENCEd
arrays of integer, double precision, and complex type. It then computes
the index into the appropriate array, knowing the needed stride.
(It uses LOC() at various points to figure that out.)
In the case of COMPLEX*16 arrays, it will only index them on multiples
of 16 bytes. (I believe IBM S/370 and VAX were popular hosts, both
of which have COMPLEX*16 in their Fortran compilers.)
I suspect I am the first one to try to compile it in a long time, and
especially with gfortran. There are some subroutines that were
written in assembly for some previous systems, like one to copy
a large array from one place to another fast. There are also some
to work with character data in A8 format, stored in double precision
array elements. (All keywords only need to be specified to the
first 8 characters.)

Guilty of equivalencing A8 to Double for dynamically allocated memory in
F77 code.

Lynn

[Ron Shepard]

Post by Jos Bergervoet
The problem here was that g77 had to be persuaded to put every
double precision complex variable on a 16 Byte boundary, which
it did not do by default (a special version of g77 might have
worked but then it no longer would have been a true f90 to f77
translator..)

Strictly speaking, f77 did not have double precision complex variables,
so it was not possible to compile/translate f90 with these complex types
into standard f77, it required the common extension. I only mention this
to remind everyone how limited of a language f77 really was. As a
practical matter however, everyone expected to to able to use double
precision complex variables. Linpack, and later lapack, even had a
standard naming convention (C*** for single complex, Z*** for double
complex) for the routines that used this extension.

Most of the f77 compilers I used in the 80s would allow any type of real
or complex variable to be equivalenced to an integer array. The fortran
standard placed no restrictions on alignment. However, it was
inefficient if the alignment was not consistent with the underlying
hardware, meaning that they might need to be aligned on 4-byte, 8-byte,
or 16-byte boundaries. If they weren't, then multiple memory fetches
were required in order to get the bytes into the register, operate on
it, and then multiple stores to return it to its destination. So I
remember being careful about this, particularly with common blocks, but
mostly for the sake of efficiency rather than to avoid internal compiler
errors. I expect there were more restrictive compilers that
required/enforced alignment, I just don't think I used them.

Elsethread, someone mentioned the necessity to have a free fortran
compiler in order to attract customer attention. In the 70s and even
early 80s, that would have been unthinkable. Each computer vendor
supplied its own fortran compiler to run on its own hardware, and they
charged the customer for this. But then in the 80s as unix became
popular, customers became accustomed to having a free C compiler. It was
practically necessary when the customer needed to patch and recompile
the kernel. The combination of a free f2c plus a free C compiler meant
that everyone had a free fortran compiler, which was quite empowering.
Then came g77 and much later gfortran to provide reliable and really
free compilers. But somewhere along the way, even unix computers stopped
providing free C compilers, and they started charging for them just like
any other language. Sun did that in the mid 90s, about the same time
they switched from SunOS to Solaris or maybe shortly thereafter. That is
when gcc became popular, even on unix machines like Sun. Then a few
years later, Linux became available, and when combined with gcc (and
later gfortran), it became possible to have an entire OS and software
environment that was free (as in beer). This is of course off topic for
the DOS/WIN16 questions because those were certainly not free, by any
meaning of the word.

$.02 -Ron Shepard

[gah4]

Post by Ron Shepard

Post by Jos Bergervoet
The problem here was that g77 had to be persuaded to put every
double precision complex variable on a 16 Byte boundary, which
it did not do by default (a special version of g77 might have
worked but then it no longer would have been a true f90 to f77
translator..)

Strictly speaking, f77 did not have double precision complex variables,
so it was not possible to compile/translate f90 with these complex types
into standard f77, it required the common extension. I only mention this
to remind everyone how limited of a language f77 really was. As a
practical matter however, everyone expected to to able to use double
precision complex variables. Linpack, and later lapack, even had a
standard naming convention (C*** for single complex, Z*** for double
complex) for the routines that used this extension.

In terms of generated code, the compiler can use two element arrays for
each complex variable, and work on the as appropriate.

Post by Ron Shepard
Most of the f77 compilers I used in the 80s would allow any type of real
or complex variable to be equivalenced to an integer array. The fortran
standard placed no restrictions on alignment. However, it was
inefficient if the alignment was not consistent with the underlying
hardware, meaning that they might need to be aligned on 4-byte, 8-byte,
or 16-byte boundaries. If they weren't, then multiple memory fetches
were required in order to get the bytes into the register, operate on
it, and then multiple stores to return it to its destination. So I
remember being careful about this, particularly with common blocks, but
mostly for the sake of efficiency rather than to avoid internal compiler
errors. I expect there were more restrictive compilers that
required/enforced alignment, I just don't think I used them.

It is more what the underlying hardware does, than the compiler.

IBM S/360 requires data to be aligned. Addressing exception if it isn't.
Fortran provides an SPIE routine to copy the data, perform the operation,
and copy back, which is very slow. Even more, high-end processors have
imprecise interrupts, where the interrupt address doesn't indicate the
failing instruction.

For S/370, the operation is performed, but (usually) slower.

The same compilers are used on both systems.

Then for some years, most hardware allowed for unaligned (but slower)
operations, until RISC came along. Most RISC processors don't allow
for unaligned data.

Post by Ron Shepard
Elsethread, someone mentioned the necessity to have a free fortran
compiler in order to attract customer attention. In the 70s and even
early 80s, that would have been unthinkable. Each computer vendor
supplied its own fortran compiler to run on its own hardware, and they
charged the customer for this. But then in the 80s as unix became
popular, customers became accustomed to having a free C compiler. It was
practically necessary when the customer needed to patch and recompile
the kernel. The combination of a free f2c plus a free C compiler meant
that everyone had a free fortran compiler, which was quite empowering.
Then came g77 and much later gfortran to provide reliable and really
free compilers. But somewhere along the way, even unix computers stopped
providing free C compilers, and they started charging for them just like
any other language. Sun did that in the mid 90s, about the same time
they switched from SunOS to Solaris or maybe shortly thereafter. That is
when gcc became popular, even on unix machines like Sun. Then a few
years later, Linux became available, and when combined with gcc (and
later gfortran), it became possible to have an entire OS and software
environment that was free (as in beer). This is of course off topic for
the DOS/WIN16 questions because those were certainly not free, by any
meaning of the word.

Sun supplied a C compiler good enough to compile the kernel, and maybe
good enough for some users.

But about that time, gcc was available and getting better. Some people
bought the optional C compiler, but others used gcc.

About that time I was using both Sun and HP-UX systems, and we had the
Fortran compiler for HP-UX, but I think not Sun.

I remember the Watcom compilers were more affordable than some,
and compiled for DOS, Windows, and OS/2, 16 bit and 32 bit.
It included at least two DOS extenders.

I remember some of the others mentioned above being more expensive
than I wanted to pay at the time.

[Ron Shepard]

[...]>> Strictly speaking, f77 did not have double precision complex
variables,

Post by gah4

Post by Ron Shepard
so it was not possible to compile/translate f90 with these complex types
into standard f77, it required the common extension. I only mention this
to remind everyone how limited of a language f77 really was. As a
practical matter however, everyone expected to to able to use double
precision complex variables. Linpack, and later lapack, even had a
standard naming convention (C*** for single complex, Z*** for double
complex) for the routines that used this extension.

In terms of generated code, the compiler can use two element arrays for
each complex variable, and work on the as appropriate.

I can see that this would work correctly for storage alignment
requirements and for simple things like additions and multiplications.
But for anything more complicated, divisions, sqrt, log, etc., the f90
translator would need to supply a full math library. Did they actually
do that, or did they fall back and assume the underlying f77 compiler
supported double precision complex as an extension? I know what linpack
and lapack did, I don't know what the f90-->f77 translators did.

Post by gah4

Post by Ron Shepard
Most of the f77 compilers I used in the 80s would allow any type of real
or complex variable to be equivalenced to an integer array. The fortran
standard placed no restrictions on alignment. However, it was
inefficient if the alignment was not consistent with the underlying
hardware, meaning that they might need to be aligned on 4-byte, 8-byte,
or 16-byte boundaries. If they weren't, then multiple memory fetches
were required in order to get the bytes into the register, operate on
it, and then multiple stores to return it to its destination. So I
remember being careful about this, particularly with common blocks, but
mostly for the sake of efficiency rather than to avoid internal compiler
errors. I expect there were more restrictive compilers that
required/enforced alignment, I just don't think I used them.

It is more what the underlying hardware does, than the compiler.

If you run a code that generates a hardware error due to alignment, then
who is to blame, the hardware or the missing operations in the compiler
that should guarantee the correct alignment?

As I said, I did not use any f77 compilers that generated those errors,
all of the f77 compilers I used added the extra operations to read and
write the nonaligned bytes. This sometimes resulted in poor performance.
The typical compiler would issue warnings, either at compile time or at
run time, so I would fix these problems as soon as possible. Perhaps I
did use compilers that would fault, but by the time my code got to them
these problems had been filtered out?

[...]

Post by gah4
Then for some years, most hardware allowed for unaligned (but slower)
operations, until RISC came along. Most RISC processors don't allow
for unaligned data.

Yes, but most of the RISC compilers I used would add the extra memory
fetches and stores to and from the registers. The operations within the
registers were done the usual way. On RISC machines, everything goes
through registers. Even the complicated instructions, such as fused
multiply and add, work on registers. Sometimes there were options to add
padding, but I tried to avoid those and to fix my code instead, for the
sake of portability.

[...]

Post by gah4
Sun supplied a C compiler good enough to compile the kernel, and maybe
good enough for some users.

Yes, through the 1980s and early 1990s.

Post by gah4
But about that time, gcc was available and getting better. Some people
bought the optional C compiler, but others used gcc.

Yes, but this was in the 1990s, It was not just Sun that started selling
their C compilers rather than giving them away, other vendors did the
same thing, especially those who invested substantial support efforts to
product optimized code. On the other hand, after gcc started producing
fast code, there were some vendors that just gave up their efforts and
started distributing the gcc compiler, presumably with their tweaks
included for their hardware.

Post by gah4
About that time I was using both Sun and HP-UX systems, and we had the
Fortran compiler for HP-UX, but I think not Sun.

I think we did the opposite. We switched to the gcc C compiler on our
Suns, and continued to pay for their fortran compiler. Our Sun
workstations were never used as production machines, but they had a nice
development environment. If our code ran on Suns, then it would
typically run on other unix machines too (initially BSD types, but later
System V types too), and that included data alignment conventions along
with various compiler extensions (which were always necessary with f77).

I think all of these things played important roles in how and why
fortran lost ground to C in the 1980s. Imagine if f90 had been released
in 1983 or so (a decade earlier than it was), and if there had been
available something like gfortran, free and capable, shortly afterwards
for all of the microcomputer, RISC, vector hardware, and early parallel
computer vendors to build from. C would have remained a high-level
assembler for OS development, and fortran would have remained the
preferred language for scientific and engineering applications. My
opinion, of course.

$.02 -Ron Shepard

[gah4]

On Sunday, August 15, 2021 at 10:41:11 AM UTC-7, Ron Shepard wrote:

(snip, I wrote)

Post by Ron Shepard

Post by gah4
In terms of generated code, the compiler can use two element arrays for
each complex variable, and work on the as appropriate.

I can see that this would work correctly for storage alignment
requirements and for simple things like additions and multiplications.
But for anything more complicated, divisions, sqrt, log, etc., the f90
translator would need to supply a full math library. Did they actually
do that, or did they fall back and assume the underlying f77 compiler
supported double precision complex as an extension? I know what linpack
and lapack did, I don't know what the f90-->f77 translators did.

I was assuming that they would supply the library.
The compilers I remember, at least from years ago, all use subroutine
calls for complex divide, and maybe for multiply. Otherwise, the other
ones are not so hard to do using the regular real library routines.


(snip, I wrote)

Post by Ron Shepard

Post by gah4
It is more what the underlying hardware does, than the compiler.

If you run a code that generates a hardware error due to alignment, then
who is to blame, the hardware or the missing operations in the compiler
that should guarantee the correct alignment?

As well as I ever knew it, and I was writing Fortran back to 1972,
it was believed that the standard didn't allow padding in COMMON.

Now, in the case where the compiler knows at compile time that the
data is misaligned, it is a good question. But not so obvious once
you pass it to another subroutine. I don't remember knowing any compiler
that figured out the misalignment at compile time and generated the
code to copy to an aligned location.

Now that you say it here, it seems obvious enough, though.

Post by Ron Shepard
As I said, I did not use any f77 compilers that generated those errors,
all of the f77 compilers I used added the extra operations to read and
write the nonaligned bytes. This sometimes resulted in poor performance.
The typical compiler would issue warnings, either at compile time or at
run time, so I would fix these problems as soon as possible. Perhaps I
did use compilers that would fault, but by the time my code got to them
these problems had been filtered out?

Which compilers were those? I knew the internal details more
in the Fortran 66 days. Things were simpler then. But also, I learned
early to put all the double precision variables first in the COMMON blocks.

Also, the compilers I had in those days printed out a variable map, with the
offset of each variable. It was easy to look through and find the misaligned
ones.

Post by Ron Shepard

Post by gah4
Then for some years, most hardware allowed for unaligned (but slower)
operations, until RISC came along. Most RISC processors don't allow
for unaligned data.

Yes, but most of the RISC compilers I used would add the extra memory
fetches and stores to and from the registers. The operations within the
registers were done the usual way. On RISC machines, everything goes
through registers. Even the complicated instructions, such as fused
multiply and add, work on registers. Sometimes there were options to add
padding, but I tried to avoid those and to fix my code instead, for the
sake of portability.

By RISC days, I was doing more C programming, and C has always been
good at padding. The usual problems with C only happened when you play
with pointers, such as an int pointer pointing to a char array that isn't aligned.
But you were supposed to know when you did that.

Post by Ron Shepard

Post by gah4
Sun supplied a C compiler good enough to compile the kernel, and maybe
good enough for some users.

Yes, through the 1980s and early 1990s.

The unbundled Sun C compiler was in the early 1990s. I don't remember
in so much detail, but also I don't remember any problems with the bundled
C compiler. ANSI C was 1989, and it might be that the bundled C compiler
stayed K&R, while the unbundled one was ANSI C.

Post by Ron Shepard

Post by gah4
But about that time, gcc was available and getting better. Some people
bought the optional C compiler, but others used gcc.

Yes, but this was in the 1990s, It was not just Sun that started selling
their C compilers rather than giving them away, other vendors did the
same thing, especially those who invested substantial support efforts to
product optimized code. On the other hand, after gcc started producing
fast code, there were some vendors that just gave up their efforts and
started distributing the gcc compiler, presumably with their tweaks
included for their hardware.

Post by gah4
About that time I was using both Sun and HP-UX systems, and we had the
Fortran compiler for HP-UX, but I think not Sun.

I think we did the opposite. We switched to the gcc C compiler on our
Suns, and continued to pay for their fortran compiler. Our Sun
workstations were never used as production machines, but they had a nice
development environment. If our code ran on Suns, then it would
typically run on other unix machines too (initially BSD types, but later
System V types too), and that included data alignment conventions along
with various compiler extensions (which were always necessary with f77).

I do remember at one point Solaris was free for R&D, but you had to pay
for production systems. All we did was R&D, so that was fine.

Post by Ron Shepard
I think all of these things played important roles in how and why
fortran lost ground to C in the 1980s. Imagine if f90 had been released
in 1983 or so (a decade earlier than it was), and if there had been
available something like gfortran, free and capable, shortly afterwards
for all of the microcomputer, RISC, vector hardware, and early parallel
computer vendors to build from. C would have remained a high-level
assembler for OS development, and fortran would have remained the
preferred language for scientific and engineering applications. My
opinion, of course.

For some time I was working in computational biology, which is mostly
string processing algorithms, and with very little floating point. Also, closer
to CS, and so mostly C. Physics was historically Fortran and tended
to stay that way, though some did lose out to C.

As I noted earlier, the SPICE circuit simulation program changed from
Fortran in version 2 to C in version 3. There is a lot of physics, but also
a lot of non-physics in it. It might have stayed Fortran if Fortran 90
was available at the time, or maybe not.

[Ron Shepard]

Post by gah4
The unbundled Sun C compiler was in the early 1990s. I don't remember
in so much detail, but also I don't remember any problems with the bundled
C compiler. ANSI C was 1989, and it might be that the bundled C compiler
stayed K&R, while the unbundled one was ANSI C.

Ah yes, now that you mention it, that might have been the key
difference. Instead of SunOS/Solaris OS, it might have been K&R/ANSI C
that triggered the move away from a bundled C compiler. That all
happened about the same time.

Sun was also trying to run on several hardware platforms at that time
too. They started off on Motorola 68x cpus, then they introduced their
own SPARC hardware, and somewhere along the line they also supported
their OS on intel 386 and later hardware. I only used SunOS/Solaris on
SPARC. My codes compiled and ran on the other combinations, but I did
not do the benchmarking or testing.

$.02 -Ron Shepard

[gah4]

On Sunday, August 15, 2021 at 11:42:36 PM UTC-7, Ron Shepard wrote:

(snip)

Post by Ron Shepard
Sun was also trying to run on several hardware platforms at that time
too. They started off on Motorola 68x cpus, then they introduced their
own SPARC hardware, and somewhere along the line they also supported
their OS on intel 386 and later hardware. I only used SunOS/Solaris on
SPARC. My codes compiled and ran on the other combinations, but I did
not do the benchmarking or testing.

There was the Sun 386i, a 386 based SunOS machine.
That was close to the time of SPARC, and got left behind pretty fast.


But then there was Solaris, and not so much later the port of Solaris
to (usually non-Sun) x86 hardware. I haven't looked so recently, but I believe
that there is still Solaris-SPARC and Solaris-x86, both having made the
transition to 64 bit hardware.

I haven't thought for a long time about which compilers they have.

[gah4]

Post by Jos Bergervoet
The problem here was that g77 had to be persuaded to put every
double precision complex variable on a 16 Byte boundary, which
it did not do by default (a special version of g77 might have
worked but then it no longer would have been a true f90 to f77
translator..)

But g77 can generate code for other architectures besides x86. A version
that generated code for the IBM System/360 would have to do that, or the
code would not run.

S/360 does not require COMPLEX*16 to be on a 16 byte boundary.
I forget now if the assemblers even have that ability.

Even REAL*16 doesn't need to be on a 16 byte boundary in memory,
though it does in registers. Each value takes two floating point
registers, either 0,2 or 4,6. There are no RX form extended precision
floating point instructions, so operands are loaded, 8 bytes at a time,
into registers. (There is actually MXD, which multiplies two double
precision values, one in memory, to an extended precision product.)

As well as I remember, the OS/360 linker only knows about 8 byte
boundaries. CSECTs are, I believe, aligned to 8 byte boundaries.

So presumably the infrastructure for doing this exists in g77
somewhere.

[gah4]

On Saturday, August 14, 2021 at 2:52:04 AM UTC-7, Jos Bergervoet wrote:

(snip)

Post by Jos Bergervoet

Post by Lorenzo Lodi
Contrary to what I wrote in my previous post, it seems that this
compiler (NAG v1.0) was released in September 1991, not in January 1992.
If I understand correctly, it was in fact a Fortran-to-C translator, and

Then also the Pacific Sierra f90 compiler should count. (I don't know
immediately what year it was from.) This was an f90 to f77 translator.

I remember Fortran 77 features in WATFIV in 1973. I presume this was
testing them out before the standard was final.

I presume that there were test compilers for Fortran 90 before the standard,
but I don't know which ones they were.

[Robin Vowels]

Post by Lorenzo Lodi

Post by Robin Vowels

Post by Lorenzo Lodi
1. NAGware Fortran 90 v1 (released January 1992 -- the first F90 compiler)

.
Salford Software produced the first Fortran 90 compiler for the PC.
It has an integrated screen graphics system.

Are you sure about that?

.
Note that I wrote that it was the first for the PC.
.

Post by Lorenzo Lodi
Several online sources indicate that the first
F90 compiler was written by Malcolm Cohen at NAG. Nag has a page
https://www.nag.com/content/personal-history-nag-fortran-compiler
https://www.nag.com/content/malcolm-cohen
Contrary to what I wrote in my previous post, it seems that this
compiler (NAG v1.0) was released in September 1991, not in January 1992.
If I understand correctly, it was in fact a Fortran-to-C translator, and
therefore relied on an external C compiler for the actual compilation stage.

That's why the Salford compiler was the first for the PC.
.

Post by Lorenzo Lodi
BTW, there should be yet another F90 compiler targeting DOS, namely
Absoft (although according to this post
http://computer-programming-forum.com/49-fortran/369cc69b8980a4c0.htm
you had to provide the 32 bit DOS extender yourself).

[Ian D Chivers]

Post by Lorenzo Lodi

Post by Robin Vowels

Post by Lorenzo Lodi
1. NAGware Fortran 90 v1 (released January 1992 -- the first F90 compiler)

.
Salford Software produced the first Fortran 90 compiler for the PC.
It has an integrated screen graphics system.

Are you sure about that? Several online sources indicate that the first
F90 compiler was written by Malcolm Cohen at NAG. Nag has a page
https://www.nag.com/content/personal-history-nag-fortran-compiler
https://www.nag.com/content/malcolm-cohen
Contrary to what I wrote in my previous post, it seems that this
compiler (NAG v1.0) was released in September 1991, not in January 1992.
If I understand correctly, it was in fact a Fortran-to-C translator, and
therefore relied on an external C compiler for the actual compilation stage.
BTW, there should be yet another F90 compiler targeting DOS, namely
Absoft (although according to this post
http://computer-programming-forum.com/49-fortran/369cc69b8980a4c0.htm
you had to provide the 32 bit DOS extender yourself).
Lorenzo

Here is some information taken from the ACM Digital Library
regarding the history of the availability of the first
Fortran 90 compiler.

A first encounter with f90
Author: Michael Metcalf
Authors Info & Affiliations
ACM SIGPLAN Fortran Forum
Volume 11
Issue 1
March 1992 pp 24–32
https://doi.org/10.1145/134304.134306
Published:01 March 1992

Partial text of article

A First Encounter with f90
Michael Metcalf
CERN, Geneva, Switzerland
(metcalf@ cernvm.cern.ch)
Abstract
A few weeks before the formal publication of the International Fortran
90 Standard, the world's first Fortran
90 compiler (f90) was announced. CERN was invited to perform
beta-testing, and the opportunity was taken
subsequently to assess the impact of Fortran 90 on the CERN Program Library.
Background
Given the long development time of the Fortran 90 standard and the
gloomy predictions about the availability
of compilers, the viability of the language, and even the difficulty of
implementing it fully, it was with some
surprise that we learned of the announcement of a full Fortran 90
compiler, called f90, by NAG (the Numerical
Algorithms Group, Oxford) on 10 June 1991. This followed the completion
of the standard by WG5 and X3J3
in the spring of 1991, and preceded the formal publication of the
standard by ISO in August [1].

[William Bader]

In the late 80's on MSDOS, I used

Prospero
Pro Fortran-77 iid 1.28

Lahey Computer Systems
F77L Version 2.10

Ryan-McFarland Corp.
RM/FORTRAN Version 1.10

If you don't need to use a vintage compiler, you could build a modern f2c, and then you only need a C compiler, which gives you more options.

William

Post by Lorenzo Lodi
[...]

Post by gah4
It depends some one what you are trying to compare.
The math processor was optional for the 386, so compilers could generate
either x87 code or software floating point. (You didn't say if you were
interested in floating point, though that is usual for Fortran.)

Thank you all for the reply!
I'll give some more context. In 1993, when a way a young boy, my parents
bought their first computer, a rather bare-bone 386DX/40MB with 4MB of
ram and a 200MB hard disk (no mouse, no sound card). It was bought
mostly for accountancy tasks, but of course I used it for games
(although it obsolescing really fast) and it played a key role in
developing my interest in computers.
By the time I got to university and became acquainted with numerical
methods and Fortran I had already moved on to a newer system, so I never
did any programming on it.
Not long ago I decided to dig up the old dinosaur from the cellar and
give it a second breath of life. It needed some work (a huge cobweb had
shorted the motherboard, the cmos battery leaked, etc.) but it is now
not only as clean as a whistle but also upgraded with 8MB of ram, a
387/DX floating point unit, a second, larger hard disk, sound card and a
Gotek Floppy Emulator (to read USB pendrives as if they were floppies)
and is now perfectly working.
In a different project, I've been preparing for some time a series of
presentations on methods to solve (=find eigenvalues and eigenvectors)
the one-dimensional Schrodinger equation (quantum mechanics), from very
basic shooting approaches to more advanced ones. Now, on a modern
computer even the slowest-converging methods would probably give
accurate results in a few seconds, so the advantage of faster method
won't probably be very striking. Of course I could artificially slow
down the machine using utilities or emulators, or run the method
repeatedly as register how many passes it does in, say, 10 seconds, but
this seems the perfect occasion to put to good use my resurrected 386.
Also, I've always wondered how much scientific computing one could do on
personal computers in the 1980s and early 1990s.
So the primary purpose is to show pros and cons of various numerical
approaches to the 1D Schrodinger equation and, as a by product and a bit
of fun, to show benchmarks on my DOS 386 and my modern PC. For this
reason I need a programming language which is supported both on the old
and the new system, and Fortran seems to be a good choice (the other
possibility I considered is ANSI C).
Development will take place on the modern system with modern compilers
(gfortran and Intel) but enforcing strict adherence to the Fortran
standard supported by the old system (F77, F90 or F95 depending on what
I can find).
At the moment I found here
https://winworldpc.com/product/fortran-powerstation/1x
a copy of Microsoft FORTRAN Powerstation 1.0a for Dos and Windows 3.1
It fits on three 1.44MB floppies and takes, installed, about 4 MB or so.
It's a F77 compiler with a few F90-like extensions (free format, enddo,
cycle, exit) and it use a 32bit DOS extender. It works fine from the
preliminary tests I did, it makes use of the FPU if present otherwise
uses software emulation.
This is a good start, but if possible I'd prefer to have a compiler with
full F90 (or 95) support.

Post by gah4
For some years, compilers would support various DOS extenders
to run 32 bit code under DOS. I believe some Fortran compilers
did that, and, though it would have been later, would still support
older versions of DOS.

You are right, ASAIK the last generation of DOS Fortran compilers (first
half of the 1990s) used 32bit Dos extenders and VxD drivers under
Windows 3.1 (https://en.wikipedia.org/wiki/VxD).
I've done a little more research (sometimes using the wayback machine to
see old versions of websites) and I can confirm the following DOS
1. NAGware Fortran 90 v1 (released January 1992 -- the first F90 compiler)
2. NAGware Fortran 90 v2.1, v2.2, v2.11, v2.18 (released between 1993
and 1997 or so -- co-developed with Salford Software)
Nag released its NAGware Fortran 95 compiler in 1997 or 1998 but ASAIK
only for Linux (no Dos versions).
3. Salford FTN90 (possibly the same as NAGware v2.x)
4. Salford FTN95 (released in 1997 --- as far as I can tell the only F95
compiler for Dos)
5. Lahey Fortran 90 (LF90) v3.0 (released in 1996 as far as I can tell)
6. Lahey Fortran 90 (LF90) v4.0, v.4.5 (released in 1998; it should also
support DOS but it's mostly a Windows NT suite as far as I can tell)
Lahey released F95 compilers as Lahey/Fujitsu, but I don't think they
support Dos.
Other people have suggested the Open Watcom F77 (thanks!). The main
problem I see (apart from the old standard) is that it takes 66.4 MB
zipped (I'd have to break it up into 50 floppies to transfer it) and
148.9 MB unzipped, which is just HUGE for my 386 system and also suggest
its memory requirements would probably overwhelm my machine. Also, I'm
not sure I'd gain very much from the Microsoft F77 compiler I already
have and which takes only 4MB or so.
I could install it on the modern machine in Dosbox and then copy to the
old system only the executable, but I'd rather avoid this route if possible.
Thank you all for the help. I'll post any further developments.

[Robin Vowels]

Post by Lorenzo Lodi
For a retrocomputing project I'd like to find a Fortran 90 or 95
compiler to be used under Dos or Windows 3.11. The idea is to compare
the performance on a 386-class computer from the early 1990s to a modern
one, and I'd be nice if I could use F90/95 instead of F77 (I still have
to write the programs I'm planning to test).
I know that Nag and Salford produced a Fortran 90 compiler for Dos, and
Salford also later released a Dos/Win16 version of its FTN95 compiler in
the mid 1990s. Anybody knows where I could find them? I searched the
internet far and wide but I couldn't find anything.

.
Lahey F90 (ELF 90) was available fairly early.

[David Billinghurst]

Post by Lorenzo Lodi
For a retrocomputing project I'd like to find a Fortran 90 or 95
compiler to be used under Dos or Windows 3.11. The idea is to compare
the performance on a 386-class computer from the early 1990s to a modern
one, and I'd be nice if I could use F90/95 instead of F77 (I still have
to write the programs I'm planning to test).
I know that Nag and Salford produced a Fortran 90 compiler for Dos, and
Salford also later released a Dos/Win16 version of its FTN95 compiler in
the mid 1990s. Anybody knows where I could find them? I searched the
internet far and wide but I couldn't find anything.

You may be able to do something with DJGPP, see http://www.delorie.com/djgpp/ and https://en.wikipedia.org/wiki/DJGPP These executables run in 32-bit protected mode.

If you go back to the early releases - circa 1995 - you may find a native g77 Fortran 77 compiler that fits on hardware from that era. If you are interested in benchmarking executable performance you may be able to cross-compile from LINUX using GCC 9 (or 10) targetting DOS/386.