Curious why there are so many FORTRAN compilers

Hi,

I’ve always used whatever compiler the company was using, whether MSFORT, LAHEY, or PGI compiler. Now that I’m on my own and these aren’t really supported, about a year ago, I decided to exclusively use gfortran as I figure it will ALWAYS be around. I’m just curious why there are so many compilers, with new ones being developed still. Maybe it’s because I don’t do anything too fancy, but my source code for current project is up over 65,000 lines of code, and I’m very happy with the execution time and ease of using gfortran with make, winteracter, and the INNO setup compiler for windows installations. Integrating C code for when I need to interact with the OS has been a breeze. Are there some huge advantages I’m missing? I’m just GCC to compile both modern fortran as well as FORTRAN 77 source files, and everything just works fine. So why use LLVM, NVfortran, Intel fortran, NAG, etc… I supposed I have a bit of FOMO, but also would like to be less ignorant.

Bryan

2 Likes

I also use gfortran and I like many of its features and its excellent performance, but there are many fortran features, some dating back to f2003 over twenty years ago, that are not supported. These include OOP features and parameterized data types (PDT). I just stumbled on another one a few days ago that involves invoking a type-bound procedure on a simple PDT – the PDT feature itself works (it is a KIND PDT, which gfortran does support), and the TBP feature works for other derived types, but when you combine them the compilation fails. The code works as expected with some other fortran compilers (e.g. flang and nagfor), so I think the code itself was alright. I think if you try to use any other free fortran compiler, you will find the same situation; some important features are either missing or only partially supported. The only full-featured compilers I’m aware of are commercial (I’m counting ifort/ifx as commercial).

2 Likes

(Adding to what @RonShepard already posted…)

The rainbow connection…

One could argue that there are at least as many C(/C++) compilers as Fortran ones, since every Fortran compiler usually has a “companion processor”.

But unlike other dev communities, where you stick to one stack, Fortran programmers have historically used more than one compiler due to perceived quality of implementation —e.g., ifort/ifx produces faster code (since it only has one instruction set to care about), but its diagnostics are kind of loose; gfortran, on the other hand, has superb diagnostics, but its backend is somewhat generic (to accommodate multiple architectures/languages), etc.

And there’s also the fact that some compilers have a particular edge you might want to take advantage of, like NAG being spot on when it comes to following the standard, nvfortran having better offloading support, flang working flawlessly on ARM chips, etc.

4 Likes

In the 1960s through the 1980s, each hardware vendor typically supported their own fortran compiler, or sometimes even multiple fortran compilers (e.g. IBM). There were only a few examples of commercial compilers that ran on a variety of hardware, none of them with a dominant market share. Nowadays, there are several such compilers. So if a programmer used a variety of machines, he almost certainly would have used a variety of fortran compilers.

But for some reason, that does not describe the way C and later C++ compilers evolved. In that community, programmers most likely started with the K&R C compiler, or maybe later the gcc compiler, and expanded only slightly beyond that to vendor compilers. When you bought a scientific workstation in the 1980s, it is likely that it came with a K&R C compiler, which was the same compiler that the OS was written with. If you needed to recompile the kernel to install a patch, that was the compiler that you would have used for that task too. That compiler would have been free, while the fortran compiler on the same machine would cost extra.

The closest thing to a portable free compiler back then was f2c (and maybe the closely related AT&T f77 compiler). The multi-platform g77 compiler came out in the mid 1990s (well after the f90 standard was adopted), and gfortran was a decade (or maybe even a little longer) after that.

2 Likes

I still use several compilers because (1) one will have a better error message for some types of error but worse for others (2) some have an 80-bit real type, others don’t, and sometimes better precision than 64 bits and faster run-time than 128 is useful (3) different outputs from different compilers often reveal bugs in my code but sometimes bugs in compilers (4) one may run faster than another (not always the same one, depending on what I’m doing).

3 Likes

Really interesting stuff guys. I like gfortran and make because I can use the same makefile on windows/wsl/or my linux laptop so developing the same software on either computer feels the same. I also like that with my customized makefile I can use make (dev,prod) (clean, all, install) and dev will have all the debug flags, where prod will have everything off so no fortran source is exposed. I don’t know how to do half the stuff you guys do, and most of it is way over my head, but I still find it fascinating.

It dates back to multiple hardware vendors having their own compiler, like IBM, Intel, etc. it wasn’t until recently that there were so many open source/free options for Fortran. A lot of people still swear by ifort even though it is being deprecated. A great source of lore for this are these series of posts by Jeff Hammond they are a great piece of Fortran culture, I believe.

My philosophy with Fortran compilers comes from designing software that can run anywhere so I like to test as many compilers as possible (it is also a good way to find bugs!). If you read the blog post above I am a Pragmatist, if something doesn’t build with every compiler I want to support I drop it.

1 Like

ChatGPT created this image when I asked it to provide a history of Fortran compilers:

Is interesting to get an idea of how things evolved over time.

5 Likes

was your prompt just that simple? I’d be nice to have this graph validated, it’d be cool to have on the main fortran lang website once as a history

edit: realized lfortran is there

I am also using GFortran along with other IDEs/compilers, but GFortran is best for general programming (though I am using it for everything). The best part is it’s open-source and portable. My portable Fortran programming setup is 260 MB (including portable gfortran, stdlib and Code::Blocks). Its always with me through 4 GB pendrive. Loved it. Sometimes I am using older version of g77 (its also portable and hardly 25MB).

2 Likes

I worked in the UK university sector from 1975-2002. My recollection is that each hardware manufacturer had their own Fortran compiler. There were also compilers for Amdahl, ICL, Data General, Prime, Sun (later Oracle) to name a few that are missing from the above.

2 Likes

NAG Fortran debuted in 1991, as the NAGWare Fortran Compiler.

2 Likes

It also gave me a text based version that could be improved for markdown integration or to iterate on and then redo a corrected final version.

There are a lot of mistakes and omissions. This graph lists VAX fortran as 1960s. @sblionel and others can fill in the details better than I can, but in the 1970s DEC had several fortran compilers for their pdp-11 (16-bit minicomputer) machines and their pdp-10 (36-bit mainframe) machines. The VAX hardware came along later, around 1979, but it ran the pdp-11 software in compatibility mode for a couple of years. I think maybe it was 1980 or 1981 when there was a separate 32-bit VAX fortran. Maybe someone can fill in the correct timelines for these compilers.

IBM also had fortran compilers for their 36-bit machines in the 1960s and 1970s. My first numerical methods course in college was on one of those machines (a 7090 I think). We punched cards for input, and the compiled “object deck” was a stack of punched cards that we would hand carry around. Then later around 2000, the IBM xlf compiler also ran on PowerPC based Macintosh computers, which are not mentioned in the graphic.

There was also a fortran compiler for the 36-bit Univac 1108 computer.

I used Microsoft fortran on Apple Macintosh computers in 1985 and 1986. I don’t remember if it was a “Fat Mac” or a Mac Plus, but I do remember experimenting with it to see what it could do. I think that compiler was written by ABSOFT and then marketed by Microsoft, which is what Microsoft did with much of their software during that period. I got pieces of my electronic structure codes running on the Mac with that compiler, but not enough to be useful at that time.

Later there was Language Systems Fortran that ran under MPW (a unix workalike enviornment) on Macs in the 1990s. This compiler also later ran directly under MacOSX in 2000, but the company merged with ABSOFT shortly thereafter. That ABSOFT fortran compiler ran on Macs, both PowerPC and Intel hardware, up until just a couple of years ago.

Alliant fortran is notable because it supported shared-memory thread-based parallel computing in the 1980s. It did that with a combination of compiler directives and code analysis. Their machines were based on their own cpus that used the Motorola 68k architecture and later based on the intel i860 RISC cpus. I also used the TCGMSG message passing and the Global Array (GA) libraries on those machines to do distributed-memory SPMD programming. The TCGMSG library was written by one of my coworkers, Robert Harrison, and that would eventually be replaced with MPI, which is still in use today on PC, cluster, and supercomputer class machines. The first versions of the TCGMSG and GA libraries were written in fortran. Those libraries are two of many examples of how fortran lost mindshare and marketshare to C during the 1980s.

I also remember using the CVC (pronouned “civic”) fortran compiler on a Cray at Livermore Lab in the 1980s that was not the Cray Fortran compiler. And Cray itself had at least three different fortran compilers for its vector machines. Its CFT77 compiler (written in Pascal, I think) was separate from its earlier CFT compilers (written in assembler), and there was a later CFT90 written in C.

I have fortran manuals for about a dozen machines from the 1980s that included various parallel machines and scientific workstations. Many of those are not mentioned in the graphic.

1 Like

I remember reading somewhere that it was the reference implementation that saved Fortran 82 85 88 90… but I’m not an LLM, so my hallucinations won’t be so easily tolerated. :laughing:

Also, what about g95? Didn’t gfortran start as a permanent fork off it?

1 Like

It was common at the time (1970s, at least) for each computer architecture to have AT LEAST one distinct Fortran compiler. If I recall correctly, IBM had two for its S\360 and S\370 systems.

At the time I joined DEC in 1978, VAX-11 FORTRAN-IV-PLUS (as it was called then) had just been introduced, as one of the programming languages offered for VAX-11/VMS (again, as it was called then.) The PDP-11 family had three separate operating systems for which Fortran was available, and each had its own name. RSX-11 had FORTRAN-IV-PLUS, RSTS/E had FORTRAN IV, and RT-11 had both FORTRAN IV (same as the RSTS one) and FORTRAN-D, a small memory compiler that was much closer to FORTRAN 66. The DEC compilers, similar to those from other vendors, had a lot of extensions, most attempting to follow the development of FORTRAN 77 (published in 1978.) Note that some models of the PDP-11 were incompatible with others. For DEC, the VAX was the first attempt to have a common architecture across all models. IBM had modeled this with the S\360.

Then there were the DECsystem-10 and DECSYSTEM-20 (yes, that’s how they were spelled) “mainframes”, each with its own, separate code base, Fortran compiler.

I don’t recall that the PDP-8 offered Fortran.

3 Likes

Fortran was instrumental in allowing many companies to even enter the computational market and all Fortran compilers were proprietary. early on Each also had extensions, some so extensive Fortran programs could be used to create general system utilities; virtually all graphics had a Fortran interface. Typically much of the graphics library was written in Fortran with just some of the device drivers written in machine code. There is a very convoluted history involving scheming, large sums of money, international competition and espionage all converging around Fortran. Many of the same issues would reoccur with Unix. But the rise of Unix and GUI standardization on X11 Windows aided the rise of C immensely and Fortran did not rise up to provide the new system interfaces required to be considered a system language, while C in combination with Unix basically did out of the box. A lot of the demise of Fortran as the primary language for almost everything was self-inflicted but its poor interface to Unix was a primary cause for the rise of other languages. So from my perspective the MAJORITY of information on the history of Fortran is missing from the chart but it does look like it serves well in providing a brief timeline for Fortran platforms still in use.
And that is more aligned with the original question, so that seems appropriate. I worked for six HPC vendors at various times. There were more issues to do with competition and customer capture than with technical development of a Fortran standard involved in the history of Fortran, which would be hard to capture in a graph. But something like this, adding in when compilers hit certain benchmarks like complying to a specific Fortran standard release, or supporting different types of parallelism and whether the languages are proprietary and platform-locked or available on many platforms, and who is available for free would be useful, with a little section on particular strengths would be informative. It might be a fascinating history and show the foibles of many approaches to trying to gain market dominance, suppress competitors, and such but the reasons there are multiple compilers currently is very different than why there were so many more historically and really does not help you sort out the current world. If I have access to a Cray the cray compiler and co-arrays are going to be of major interest. If I instead mostly use Fortran on an MSWIndows box as a home hobbiest and do not want to spend a lot of money on a powerful infrastructure I am looking for something totally different. If I am on that same platform but doing large commercial work I probably want to pay for a compiler with powerful profilers, debuggers, and other infrastructure. I lived a good amount of the history but I think today the question is what to do with the compilers I can stil use today, and trying to ascertain what their future is instead.of pondering the past. It would make a good book for an business and econimics class but would not help too much to create a new optimal Fortran code. On the other hand figuing out which compiler to develop for is rather unique to Fortran compared to the many single-source languages available today. Understanding the good and the bad of Fortran being driven via a standard versus a open-source evolutionary process is difficult for a lot of people not as concerned with small bugs being able to kill people and mutli-billion dollar projects, how dramatically differerent performance can be, whether scalability matters, whether the language you pick is going to last decades or whether your project is going to turn you into a maintenance man instead of a developer because the language is unstable, … there are a lot of reasons to pick Fortran, and a good number of reasons to pick a particular Fortran that really do not apply to projects where optimization and program life cycle are not important, that is usually the dominant type of code being developed in a good number of languages.

1 Like

PDP-8 definitely had a Fortran compiler. I used it on a TSS-8 system ca 1971 or 1972. It was pretty stripped down. No user-written subroutines or functions, so almost FORTRAN 1.

Their 18-bit systems, culminating with the PDP-15, had Fortran as well. The lab I worked at in college was just replacing their PDP-15 with a Data General Eclipse. I also ported their (finite element analysis) codes to VAX/VMS 1.0 on the second VAX in Arizona, and a PDP-11/70 running IAS.

1 Like

G95 is missing in the gfortran history.

The Control Data Corporation (CDC) Fortran compilers are missing. That is of importance as they had in the 70s the (now modern) array syntax (the historic Cray’s systems were register-to-register based, wheras the Star100, Cyber 200/205 and ETA-10 systems had realy long vectors going from memory-to-memory). What I am missing from the Cyber 205 syntax in the modern syntax are the bit vectors (they are partially there as masks in the where, sum, merge statements etc. but iirc one cannot play with masks in the same way).

1 Like

Yes, g95 was started by by Andy Vaught. But as he let others help him develop it, schisms happened, a fork appeared and gfortran came into existence. Once gfortran officially became part of the gnu compiler collection, the rest is history.

CDC had Fortran compilers all the way back to the CDC 160A (a small 12-bit computer which later became the basis of the peripheral processors in the 60-bit machines), the 48-bit 1604 and the following 3000 series. On the 60-bit machines there was RUN Fortran, then FTN, then FTN5. FTN5 was one of the first Fortran 77 compilers.

The STAR-100, and CYBER-203/205 were 64-bit machines and had their own compilers with various extensions for vector processing. Then the CYBER-180 series running NOS/VE (also 64-bit) had their compiler.

I used RUN, FTN, and FTN5 quite a bit. All of the early compilers were written in assembly language (early in ASCENT, later in COMPASS). Maybe some bits of SYMPL (CDC’s stripped down version of JOVIAL) in FTN5. I don’t know much about the NOS/VE compiler. I’d assume it was mostly written in CYBIL - which was a CDC extension of PASCAL. But that was about the time I left the CDC world. So never played with NOS/VE or its product set.

1 Like