[TUHS] What It Takes to Read Lions in 2026

[Clem Cole via TUHS]

Will/Matt,

You both make interesting observations, and I tried to go back a little and
remember what resources I had when I encountered Lions (and made my
xerographic copy).  At the time (which I think was late 1977 or early 78),
I had my own copy of the 1974/75 PDP-11 04/34/45/55 Processor Handbook [
https://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP-11_04-55_Processor_Handbook_1976.pdf]
and the 1976 PDP-11 Peripherals Handbook†  [
https://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP-11_PeripheralsHbk_1976.pdf]
 Note I had the 34 docs, not the 40 docs.   I also had access to the docs
from Sixth Edition, such as the C Reference manual.

Also remember that I was not using it as a course text, which is why he
wrote it.  When I discovered it, the book was just a wonderful resource
that helped explain in more detail a lot of things I already had an inkling
of, and as I look back, probably corrected some misunderstandings too.

That said, before I read Lions, I had already been programming UNIX for a
year or two on the 11/40E (IUS and SUS) in the CS Dept.  We had converted
from Fifth Edition to Sixth (I personally had very brief experiences with
Fifth - it was in my "what is this strange system and language phase,"
introduction to UNIX having come over from BLISS and both a DEC and IBM
flavor of how OS's were supposed to present themselves).  But in the summer
before I saw Lions, we had received our first 11/34 in the EE Dept.  We
couldn't just use Dennis's distribution tape, since a 34 is a 40-class
processor (which are similar but different enough; it's not going to "just
work" — *i.e*., not something the stock Sixth Edition knew about).  So, we
bootstrapped the EE 34 from IUS, which was tricky because we had to add 34
support to mch40.s, more importantly, the 34 didn't have the CSV/CRET in
the writable microcode of the 11/40Es that the C compiler on the CS systems
expected (I have memories of walking back and forth between the two
buildings creating yet another RK05 boot image when we found some other
important program that was expecting CSV/CRET but weren't far/stable enough
along in the bootstrap to correct it ourselves).

FWIW: I had had some exposure to RT-11 on an 11/05 [running from DEC
cassette tapes], as well as programming the PDP-8 running TSS/8 and the 10s
under TOPS, as well as working for the Computer Center supporting York/APL
on the IBM 360/67.  But I think most importantly for my UNIX kernel
experience, I had started to work on the Computer Center's version of the
CMU Front End, trying to add support for the 11/45 they had running RSTS
for the School of Humanities and Social Science.   As I have mentioned in
other emails, the CMU FE was a standalone system (no OS) with a ton of
serial ports, a card reader and printer, and some sort of interface to
larger systems (in the CC's case, the 360 for interactive serial ports and
as an RJE station for the 360 and Univac 1008, and we were adding the then
new RSTS system).  At that point, it was based on an 11/15 (no MMU, of
course, and the code was primarily in BLISS-11 with a very small assembler
assist).  The key is I was already inoculated with the core PDP-11 ISA and
differences between models, so much of what you are commenting about with
PDP-11-ism, such as the RESET instruction or the PARS, was already
something I had learned before. To me, Lions was explaining how Ken uses
them in the kernel.

My point is I didn't walk into reading Lions without some core experience
with the PDP-11 family.  Some of the peripherals, like the KL/DLs and
clock, I was certainly extremely familiar with, and I already understood
about MMUs (the 67 running TSS was IBM's first VM system). Across so many
different CMU systems, we had aftermarket disks on most of them [the DEC
RP03/04 were made by Univac, but they were actually clones of the IBM
2314/2316 (only slightly different)].   IIRC we had CDC flavors of them
which they called the 84x series, and IIRC we had to modify the rp.c driver
slightly to make them work properly.  So I had already learned how to hack
the disk drivers by then.     But I never had access to real manuals for
any of the DEC peripherals other than the 76 Peripherals Handbook until we
got one of the first RK07s and the RK611/711 controller.   Danny Klein and
I wrote the first UNIX driver for it, cribbing from the already hacked
RP04/5/6 driver and reading Dennis' V6 driver manual.  I had already been
doing a small amount of the kernel mods by then, and we had started to
write fsck(8) as well.  But when I saw it (and made my own copy), I thought
Lions helped me better understand the system than I had before.  It
certainly gave me more confidence about what subsystems I would attack
(more in a minute).

At some point, but it had to have been after I saw Lions, Ted Kowalski had
a xerographic copy of the proofs for K&R1 in a binder (which I copied), and
by late 78 I had obtained a xerographic copy of the "Unix program
description" doc that Matt referred to (I think I got that from Phil Karn,
but it might have been Ted).

FWIW: A few years later, my old friend and then colleague at Tektronix,
Mike Zuhl, made an interesting observation, which I think actually plays
into your comments about Lions.  Zuhl was one of the Purdue EE UNIX folks
(like the late George Goble and Ward Cunningham).   Zuhl said: *"Hacking on
the Unix kernel is a lot like riding a motorcycle.  At first you are scared
sh*tless that you don't want to screw up.   After a while, you get
confident in your abilities and are willing to try anything.  Finally, you
realize it is really just an incredibly beautiful hack that works in a
manner like no other, and you start to respect it and those that came
before you*."

For me, reading Lions was part of my transition in the third phase.  He
explains things I basically knew before at a more macro level.

My thoughts/recollections if it is of any help,
Clem

†  To this day, I still think the 1976 Peripherals Handbook was the best
one DEC made, and if you are looking at Sixth or Seventh Editions, it is
really all you need for most of the peripherals they supported.   Later
ones include some information about later products such as the RL01/2 and
RK06/7, but they dropped many of them outright in some cases, and in others
the core descriptions are not nearly as detailed/useful.

On Tue, Jul 28, 2026 at 2:41 PM segaloco via TUHS <tuhs at tuhs.org> wrote:

> On Tuesday, July 28th, 2026 at 10:14, Will Senn via TUHS <tuhs at tuhs.org>
> wrote:
>
> > Lions is great, but today's reader needs more of a leg up. I think it
> > illustrates how much architectural knowledge his original audience could
> > take for granted. Nearly fifty years later, recovering that context has
> > become part of reading the book. So, reading through Lions in 2026 is an
> > archaeological dig, really :). That said, if you're planning to read
> > Lions with any depth, be sure to minimally have on hand:
> >
> > * Lions Commentary
> >
> > * Lions Source Code
> >
> > * PDP-11/40 Processor Handbook
> >
> > * KT11-D Memory Management Option User Manual
> >
> > * Repeatable notes for setting up a working lab
> >
> > Later,
> >
> > Will
> >
>
> For the record, the intro does indicate what auxiliary knowledge may be
> necessary, pointing the reader to the manual, several papers such as C
> tutorials and UNIX for Beginners, as well as listing knowledge of the
> following PDP-11 hardware useful:
>
> - PDP11/40
> - RK05
> - LP11
> - PC11
> - KL11
>
> You also do get a bit of hardware exposition, albeit not too much, in
> Chapter 2.
>
> This implies having the PDP-11 Peripherals Handbook on hand would also be
> helpful.  Naturally our biases allow us to overlook this, but having both
> the UNIX Assember Manual and C Reference Manual on hand would be helpful to
> the uninitiated as those are the two languages at play in the source
> volume.  Not sure how necessary this would be in practice but UNIX is an
> ASCII system, so non-ASCII-ites, however rare these days, would be going in
> with some unhelpful biases, but I don't know if that would peg the ASCII
> standard as required context.  I'm a sucker for building complete reference
> documentation graphs...so I'm going to hold my urge further for now.
>
> Still, it would be an interesting exercise to pursue the full graph of
> primary references needed to establish a normative reference graph for
> Lions's Commentary.
>
> Will, I don't know if this would be a comparable follow-on project, but
> there is the Program Description document published with USG UNIX that
> serves as another detailed analysis of the UNIX kernel[1] that may be worth
> inspecting with a similar lens.  By the way, I have a later hardcopy of [1]
> issued with Program Generic 3.  Unfortunately its just a reprint of the
> Program Generic 2 version and does not include the kernel changes in PG3,
> but it is complete, so I plan on scanning it in my next round of documents.
>
> - Matt G.
>
> [1] - unix_program_description_jan_1976.pdf
>