|
Unix Programming - Software Is a Many-Layered Thing - Case Study: C Considered as Thin Glue
The C language itself is a good example of the effectiveness
of thin glue.
In the late 1990s, Gerrit Blaauw and Fred Brooks observed in
Computer Architecture: Concepts and Evolution
[BlaauwBrooks] that the
architectures in every generation of computers, from early mainframes
through minicomputers through workstations through PCs, had tended to
converge. The later a design was in its technology generation, the
more closely it approximated what Blaauw & Brooks called the
“classical architecture”: binary representation, flat
address space, a distinction between memory and working store
(registers), general-purpose registers, address resolution to
fixed-length bytes, two-address instructions,
big-endianness,[46] and data types
a consistent set with sizes a multiple of either 4 or 6 bits (the
6-bit families are now extinct).
Thompson
and Ritchie
designed C to be a sort of structured assembler for an idealized
processor and memory architecture that they expected could be
efficiently modeled on most conventional computers. By happy
accident, their model for the idealized processor was the
PDP-11, a
particularly mature and elegant minicomputer design that closely
approximated Blaauw & Brooks's classical architecture. By good
judgment, Thompson and Ritchie declined to wire into their language
most of the few traits (such as little-endian byte order) where the
PDP-11 didn't match it.[47]
The PDP-11 became an important model for the following
generations of microprocessor architectures. The basic abstractions
of C turned out to capture the classical architecture rather neatly.
Thus, C started out as a good fit for microprocessors and, rather than
becoming irrelevant as its assumptions fell out of date, actually
became a
better
fit as hardware converged more
closely on the classical architecture. One notable example of this
convergence was when Intel's 386, with its large flat memory-address
space, replaced the 286's awkward segmented-memory addressing after
1985; pure C was actually a better fit for the 386 than it had been
for the 286.
It is not a coincidence that the experimental era in computer
architectures ended in the mid-1980s at the same time that C (and its
close descendant C++) were sweeping all before them as
general-purpose programming languages. C, designed as a thin but
flexible layer over the classical architecture, looks with two
decades' additional perspective like almost the best possible design
for the structured-assembler niche it was intended to fill. In
addition to
compactness,
orthogonality,
and detachment (from the machine architecture on which it was
originally designed), it also has the important quality of
transparency that we will discuss in Chapter6. The few language designs since that
are arguably better have needed to make large changes (like
introducing garbage collection) in order to get enough functional
distance from C not to be swamped by it.
This history is worth recalling and understanding because C
shows us how powerful a clean, minimalist design can be. If
Thompson and
Ritchie had
been less wise, they would have designed a language that did much
more, relied on stronger assumptions, never ported satisfactorily off
its original hardware platform, and withered away as the world changed
out from under it. Instead, C has flourished — and the example
Thompson and Ritchie set has influenced the style of Unix development
ever since. As the writer, adventurer, artist, and aeronautical
engineer Antoine de Saint-Exupry once put
it, writing about the
design of airplanes:
La perfection est atteinte non quand
il ne reste rien ajouter, mais quand il ne reste rien
enlever.
(“Perfection is
attained not when there is nothing more to add, but when there is
nothing more to remove”.)
Ritchie and Thompson lived by this maxim. Long after the
resource constraints on early Unix software had eased, they worked at
keeping C as thin a layer over the hardware as possible.
|
Dennis used to say to me, when I would ask for some
particularly extravagant feature in C, “If you want PL/1, you know
where to get it”. He didn't have to deal with some marketer saying
“But we need a check in the box on the sales viewgraph!”
|
|
--
Mike Lesk
|
|
The history of C is also a lesson in the value of having a
working reference implementation
before
you
standardize. We'll return to this point in Chapter17 when we discuss the evolution of C and
Unix standards.
[an error occurred while processing this directive]
|
|