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.
On 11.08.21 16:07, Lorenzo Lodi wrote:
For a retrocomputing project I'd like to find a Fortran 90 or 95Might check (older) watcom fortran.
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.
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.
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.
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.
Also, I've always wondered how much scientific computing one could do on personal computers in the 1980s and early 1990s.
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.
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.
.
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.
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..)
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).
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.
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..)
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..)
(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.
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..)
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.)
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:
And in tandem with g77 it translated to machine language. So that wasThen 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.
not the problem..
.compiler was the "F" compiler,
(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
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!)
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..)
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.
On Sunday, August 15, 2021 at 12:09:56 AM UTC-7, Ron Shepard wrote:[...]>> Strictly speaking, f77 did not have double precision complex
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.
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.
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.
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.
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.
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.
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.
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.
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
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..)
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 159 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 98:47:51 |
| Calls: | 3,209 |
| Files: | 10,563 |
| Messages: | 3,009,783 |