[TUHS] First Unix-like OSes not derived from AT&T code?

[Clem Cole]

On Wed, May 11, 2022 at 12:44 PM Paul Winalski <paul.winalski at 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].
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220511/7a3d32df/attachment.htm>