• Fortran 90/95 compilers for Dos/Win16

    From Lorenzo Lodi@21:1/5 to All on Wed Aug 11 16:07:20 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sjouke Burry@21:1/5 to Lorenzo Lodi on Wed Aug 11 16:44:40 2021
    On 11.08.21 16:07, Lorenzo Lodi wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Sjouke Burry on Wed Aug 11 13:37:17 2021
    On 8/11/2021 9:44 AM, Sjouke Burry wrote:
    On 11.08.21 16:07, Lorenzo Lodi wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lorenzo Lodi on Wed Aug 11 15:19:51 2021
    On Wednesday, August 11, 2021 at 7:07:24 AM UTC-7, Lorenzo Lodi wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lorenzo Lodi on Wed Aug 11 17:09:07 2021
    On Thursday, August 12, 2021 at 12:07:24 AM UTC+10, Lorenzo Lodi wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lorenzo Lodi on Thu Aug 12 04:41:38 2021
    On Thursday, August 12, 2021 at 4:16:13 AM UTC-7, Lorenzo Lodi wrote:

    (snip)

    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)

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lorenzo Lodi@21:1/5 to All on Thu Aug 12 13:16:06 2021
    On 12/08/2021 00:19, gah4 wrote:
    [...]
    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lorenzo Lodi on Fri Aug 13 11:06:26 2021
    On Thursday, August 12, 2021 at 9:16:13 PM UTC+10, Lorenzo Lodi wrote:
    On 12/08/2021 00:19, gah4 wrote:
    [...]
    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.
    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)
    .
    Salford Software produced the first Fortran 90 compiler for the PC.
    It has an integrated screen graphics system.
    .
    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.
    .
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lorenzo Lodi@21:1/5 to Robin Vowels on Sat Aug 14 11:13:16 2021
    On 13/08/2021 20:06, Robin Vowels wrote:

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jos Bergervoet@21:1/5 to Lorenzo Lodi on Sat Aug 14 11:51:00 2021
    On 21/08/14 11:13 AM, Lorenzo Lodi wrote:
    On 13/08/2021 20:06, Robin Vowels wrote:

    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

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

    --
    Jos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Jos Bergervoet on Sat Aug 14 03:57:10 2021
    On Saturday, August 14, 2021 at 7:52:04 PM UTC+10, Jos Bergervoet wrote:

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lorenzo Lodi on Sat Aug 14 03:53:26 2021
    On Saturday, August 14, 2021 at 7:13:42 PM UTC+10, Lorenzo Lodi wrote:
    On 13/08/2021 20:06, Robin Vowels wrote:

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

    That's why the Salford compiler was the first for the PC.
    .
    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Billinghurst@21:1/5 to Lorenzo Lodi on Sat Aug 14 04:10:53 2021
    On Thursday, August 12, 2021 at 12:07:24 AM UTC+10, Lorenzo Lodi wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jos Bergervoet@21:1/5 to Robin Vowels on Sat Aug 14 19:50:04 2021
    On 21/08/14 12:57 PM, Robin Vowels wrote:
    On Saturday, August 14, 2021 at 7:52:04 PM UTC+10, Jos Bergervoet wrote:

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

    .
    (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!)

    --
    Jos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Jos Bergervoet on Sat Aug 14 13:05:20 2021
    On Saturday, August 14, 2021 at 2:52:04 AM UTC-7, Jos Bergervoet wrote:

    (snip)

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to All on Sat Aug 14 13:01:01 2021
    (snip)

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jos Bergervoet@21:1/5 to All on Sat Aug 14 23:04:23 2021
    On 21/08/14 10:01 PM, gah4 wrote:

    (snip)

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

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

    --
    Jos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Jos Bergervoet on Sat Aug 14 15:06:06 2021
    On Saturday, August 14, 2021 at 2:06:04 PM UTC-7, Jos Bergervoet wrote:

    (snip)
    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.
    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.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to All on Sat Aug 14 21:49:37 2021
    On 8/14/2021 5:06 PM, gah4 wrote:
    On Saturday, August 14, 2021 at 2:06:04 PM UTC-7, Jos Bergervoet wrote:

    (snip)
    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.
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Jos Bergervoet on Sat Aug 14 20:38:15 2021
    On Sunday, August 15, 2021 at 3:52:04 AM UTC+10, Jos Bergervoet wrote:
    On 21/08/14 12:57 PM, Robin Vowels wrote:
    On Saturday, August 14, 2021 at 7:52:04 PM UTC+10, Jos Bergervoet wrote:

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

    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.

    (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!)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Jos Bergervoet on Sun Aug 15 02:09:52 2021
    On 8/14/21 4:04 PM, Jos Bergervoet wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Sun Aug 15 02:17:37 2021
    On Sunday, August 15, 2021 at 12:09:56 AM UTC-7, Ron Shepard wrote:
    On 8/14/21 4:04 PM, Jos Bergervoet wrote:
    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.

    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Sun Aug 15 12:41:06 2021
    On 8/15/21 4:17 AM, gah4 wrote:
    On Sunday, August 15, 2021 at 12:09:56 AM UTC-7, Ron Shepard wrote:
    [...]>> 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.

    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.

    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?

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

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

    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to All on Sun Aug 15 13:57:27 2021
    On Sunday, August 15, 2021 at 10:41:11 AM UTC-7, Ron Shepard wrote:

    (snip, I wrote)
    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)
    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.

    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.

    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.

    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.

    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.

    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Mon Aug 16 01:42:33 2021
    On 8/15/21 3:57 PM, gah4 wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Tue Aug 17 11:48:40 2021
    On Sunday, August 15, 2021 at 11:42:36 PM UTC-7, Ron Shepard wrote:

    (snip)
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Bader@21:1/5 to Lorenzo Lodi on Sun Sep 19 13:03:39 2021
    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

    On Thursday, August 12, 2021 at 12:16:13 PM UTC+1, Lorenzo Lodi wrote:
    On 12/08/2021 00:19, gah4 wrote:
    [...]
    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.
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ian D Chivers@21:1/5 to Lorenzo Lodi on Mon Sep 20 15:26:52 2021
    On 14/08/2021 10:13, Lorenzo Lodi wrote:
    On 13/08/2021 20:06, Robin Vowels wrote:

    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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Quadibloc@21:1/5 to Jos Bergervoet on Sun Oct 31 20:01:39 2021
    On Saturday, August 14, 2021 at 3:06:04 PM UTC-6, Jos Bergervoet wrote:

    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.

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

    John Savard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Quadibloc on Mon Nov 1 09:35:26 2021
    On Sunday, October 31, 2021 at 8:01:41 PM UTC-7, Quadibloc wrote:
    On Saturday, August 14, 2021 at 3:06:04 PM UTC-6, Jos Bergervoet wrote:

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)