Of course you are right about CDC’s compilers in the 60s. My point was the vector syntax (I still have a manual from those days, and the use of VAST, a tool that converted the source into vector syntax so you really could see what was going to be done - and tweak that of course). I really liked working under NOS/VE (spent a lot of time on 180/990, and later the 960 - the 910 do not count as they were SGIs with the 68020 CPU, runing Irix (Unix)).
An 910 anecdote though… because it was a Unix workstation, some software specialists were convinced that C would deliver faster code than f77. Since the SGI C and f77 compilers differed only in the frontend—the pseudo code generator and assembler were the same—a clean competition was possible. A number of calculations were defined using predefined longer arrays. Everyone was allowed to use whatever they wished. Whatever the C programmers did (including wild messing around with pointers), Fortran remained 10% faster (thanks to common blocks ;- ). This was on a MIPS R3000 910 (SGI Indigo).
Executive summary: Pathscale is a branch off the Cray f90 compiler.
Longer story:
A number of computer manufacturers historically used “off the shelf” compiler front ends, and then wrote their own back ends for their particular hardware. A common f77 front end in the '80s and '90s was from Edison Design Group - which packaged it with their C and C++ front ends. AFAIK, Edison never made a f90 front end.
In the early '90s, Cray decided to market their f90 front end to some other vendors. Notable were Absoft and Sun. Then after the 1996 Cray-SGI merger, it was used in the MIPSpro compiler suite. Somewhat later, I think about the time SGI switched to using Intel chips (and using Intel’s compilers) instead of MIPS, they decided to release the compiler source to the public domain. A group of folks used this as the basis of the Pathscale compiler.
That would take turning all Fortran standard and compiler development over to something like a Fortran Foundation which is never going to happen because of the entrenched commercial interests of some of the current Committee members and the political interests of the ISO bureacrats. Also it would take someone with very deep pockets (are you listening Elon) to fund it.
There were also 2 more compilers that ran on CDC hardware that haven’t been mentioned. One was Minnesota Fortran - mnf, and the other was Waterloo Fortran wativ.
The MNF compiler, and its successor M77, were from the U of Minnesota - not CDC proper. There was also RUNT from U of Washington.
Watfor and watfive ran on IBM iron.
These were all “student” compilers - designed for better diagnostics. Since student programs were presumably short, and failed frequently, there was less emphasis on optimization. Though they did offer a few features the vendor compilers didn’t.
Not sure, as I’ve never used them. My IBM 360/370 experience is almost non-existent.
I’m actually getting up to speed now on the 1960-era IBM 1401s at the Computer History Museum. They have two that are operational. Re-learning my punch card skills on their IBM 026 card punches. Believe it or not, after 45+.years, some of that muscle memory is still there!
The 1401 is a business oriented computer. Variable width decimal arithmetic. Very different than the computers normally used for scientific computing. But it does have a rudimentary FORTRAN II compiler. Reportedly takes 60+ passes to compile a program. Haven’t gotten to the point where I’ve been allowed to try a Fortran program on it yet. According to the docs, there was also a FORTRAN IV compiler for it. Not sure if the CHM has it or not.
Another one I worked with was the Floating Point System compiler. Floating Point Systems - Wikipedia This was on a combined DEC/FPS system at Imperial College.
As FPS was dying back in the '80s, their compiler group was spun off and formed the Portland Group. The PGI compilers have continued to evolve to this day - now as part of Nvidia.
I also used their machines. https://doi.org/10.1002/qua.560240865 One thing I remember about them is that they had two fortran manuals, a user manual and a language manual. The user manual documented the compiler options and so on; the compiler ran on the VAX front end machine, so it was actually a cross-compiler. The language manual was just the ANSI f77 document! Somehow, I did not know the connection to the later PGI compilers.
After FPS crashed, Cray was “asked” by the gov’t to purchase the remaining assets. I flew up to Portland a couple of times to see what they had. Instead of a VAX, they had developed a server that used ECL SPARC chips that ran Solaris, had a vector processor add-on, and an attached Matrix Co-Processor. The MCP was a configuration of Intel i-860 chips configured in an interesting way to take advantage of their on-chip data caches. PGI provided the compilers.
As part of Cray, they developed a follow-on SPARC-based machine - to be called the CS-6400 “Super Dragon”. (I still have a Super Dragon t-shirt. It is very cool.) It was to be sold for database and other markets where the traditional Cray vector machines were less suited. As part of the Cray-SGI merger, and much to the dismay of a lot of SGI folks, it got sold off to Sun - who then turned it into the very successful ES 10000.
I thought the intel i860 chips had great potential. Each one was capable of 40 MFLOPS, they were cheap enough to put in PCs, and capable enough to configure as massively parallel supercomputers, and everything in between. I never understood at the time why they failed at gaining marketshare. In hindsight, I think it was because the major computer companies at the time (DEC, Sun, Cray) started playing Monopoly, which led to the dot com bust in the late 1990s. The successful ES 10000 you mention eventually did not have the i860 chips, it was built around the arguably less capable Sun sparc chip, a business decision for profits rather than a technical decision to benefit their customers. I worry that something similar is happening now with AI based data centers driving both stock market investments and computer hardware.
Actually the PDP-8 range had two very different Fortran compilers. One was around Fortran-II level and the other around Fortran-IV and this one worked with the floating point hardware add-on that one could buy. Since we had one of these most of our software used DEC Fortran-IV but this had the snag that it could only access files declared and connected to a numbered I/O unit in the job control. The Fortran-II compiler had the equivalent of an OPEN statement so it could access any file on the file system chosen at run-time. This was also very important to us, so I wrote code in Fortran-II to write the job-control for the Fortran-IV job which did the real data processing. What peculiar work-around we had to put up with in those days (early to mid 1970s).