[TUHS] Bootstrapping UNIX - how was it done
Clem Cole via TUHS
tuhs at tuhs.org
Tue Mar 24 12:07:45 AEST 2026
On Mon, Mar 23, 2026 at 5:34 PM Noel Chiappa via TUHS <tuhs at tuhs.org> wrote:
>
> 2 - Move a set of existing software from one type of machine to another. (A
> much more common event, now that we have portable software.
>
Noel, I'm not sure I'm parsing this. Do you want me to move the kernel and
all its utilities, or move the application SW?
Writing portable *application* software goes back to the 1960s. It was why
there was a push for formal programming language standards, such as what
was developed for FORTRAN-66 (ANSI X3.9-1963) and the NBS [today's NIST]
1967 FORTRAN test suite. In the case of Algol-60 [The Revised Report
(1963), although the NPL/Wichmann validation test do happen until 10 years
later], we had a less formal standard, but there was something. And with
the COBOL-60 report, there was something [although until COBOL-68 - ANSI
X3.23-1968 for a formal standard]. Still, before developing its own formal
language standard, ANSI established Task Group X3.4.4 in 1963 to develop
"test problems" to test COBOL features, laying the groundwork for formal
validation. Thus, by the late 1960s, the Navy had created its COBOL
Validation System.
So I don't think the idea of writing portable software was really new with
UNIX. It was pretty common through the 1960s and beyond. In fact, meeting
the standard and then adding features (Microsoft "embrace and extend) was
very much the norm for most manufacturers. The system vendors wanted to
lock in the applications to their systems, *so you could not easily move
them*. It was common everywhere, with IBM and CDC notorious for doing so
in their language implementations. Althought the most successful at this
was the DEC VMS FORTRAN compiler, which, if you talked to customers, they
would swear their code was written in FORTRAN-77. By the time of the
superminis, Crayettes, and UNIX workstation vendors that offered FORTRAN,
they all had to add the many VMS FORTRAN extensions to get customers' code
to compile. FWIW: the out-of-the-box, the f77 compiler in UNIX Seventh
Edition was ok, but could not pass the NIST FORTRAN Compiler Validation
System (FCVS) without a good bit of work. And it did not support the VMS
extensions either, so moving code from VMS was often nightmarish if that
was what you had. DEC eventually moved (and sold as an option) the Vax VMS
Compiler to later editions of the VAX, although they bundled V7's f77 in
both Ultrix-11 and Ultrix-Vax standard.
Going back to the OS, and porting it as others have already discussed a
bit. Other than Burrough's, with the Master Control Program (MCP) being
written, is ESPOL. What was really new with UNIX was that the kernel itself
was mostly in an HLL, so we now had the possibility of moving the OS from
one HW system to another. Remember that, until that time, if you look at
systems from DEC, IBM, and the rest of the "BUNCH" [minus Burroughs], their
OS had been written in assembler (for efficiency, of course). High-level
languages gave great programmer efficiency, but they were not deemed
appropriate for "production" use in the "system code" (including for the
compiler itself in many cases). It was not until Wulf's BLISS Compiler
experiments and the publication of the Green Book in the 74-75 time frame
that people began to seriously believe it was possible to create what Wulf
called a "Production Quality Code Generator." What is interesting is that
at the time, Dennis's code generator/optimizer for C on the PDP-11 was
almost a toy when you compared it to BLISS-11 [but even DEC - well Culter,
famously refused to use BLISS for writing the VMS kernel (in fact when VMS
was moved to Alpha and Itanium years later, the solution that was developed
was to create a DEC GEM compiler "front-ed" that accepted VAX assembler
and generated code for the new system. VSI still does that with the
INTEL*64 and ARM architectures.
Anyway, coming back to C, the fact is, Dennis compiler and Steve Johnson's
PCC, while "not as good" as ones with a "Green Book" style optimizer, they
were "good enough," and retargeting C was done anyway. [Plus, eventually
enough of a new generation of compiler writers had graduated, educated in
the new techniques, and Wulf-style optimizers became the norm for most
languages, and in particular C]. So the idea of having a "portable OS,"
particularly if you had a "production quality compiler," was no longer
considered silly. In fact, the world switched, and it became silly to
think about writing the core OS in anything but an HLL.
More information about the TUHS
mailing list