On Wed, May 11, 2022 at 12:44 PM Paul Winalski <paul.winalski@gmail.com> wrote:
Many of the non-standard innovations in VAX Fortran were adopted by
IBM and other vendors under pressure from the Fortran community.  By
1985 DEC was losing sales to other vendors in the HPTC world due to
lack of VAX Fortran features in f77. 
I would put it a little differently.   As far as I'm concerned the best piece of marketing that DEC ever did was convincing the world that VMS FTN was standard Fortran-77.   So when you went into a VMS shop trying to sell a UNIX box (from any manufacturer), many (most) had written their code in VMS FTN, and thus your Fortran compiler needed to accept the DEC VMS extensions.   The fact was most customers swore up and down they had written their code in F77, but the UNIX compiler would die trying to compile it and as Paul point out, even if you did get the local compiler to accept your sources from a syntactical standpoint, the code generator and optimizer used in the PCC-based F77 compilers was not int he same league at the DEC or IBM compilers of the day.

As I have mentioned on this list previously, a year after MASSCOMP was founded and about 5 years before Sun figured this issue out, we had hired a number of ex-DEC languages folks and they wrote our compiler C and Fortran compilers using the same optimization techniques that DEC had honed.  In fact, one of the reasons why we added the RSX/VMS AST scheme to RTU, was to make porting customer code from VMS that much easier [tjt and I drew the line on QIO since we already had a different async I/O scheme, but UNIX signals were so far from AST it was never going to work -- again as I have said, I can build UNIX/POSIX signals from ASTs, but not the other way round].