[TUHS] What It Takes to Read Lions in 2026

[Will Senn via TUHS]

Omg. Ha. I never connected that. Of course that’s what it is :). Still, it is also where he really begins talking about how stuff works. The first five chapters are more background and orientation.

Will


Sent from my iPhone

> On Jul 30, 2026, at 11:55 PM, Otto Moerbeek <otto at drijf.net> wrote:
> 
> 
> "Getting Started" talks about the machine, not about the reader :)
> 
> -Otto
> 
>> On Thu, Jul 30, 2026 at 07:56:10AM -0500, Will Senn via TUHS wrote:
>> 
>> Clem,
>> 
>> Wow. This makes so much sense. I "randomly" picked page 28 as a starting
>> point, never mind that the section was called "Getting Started". That was
>> possibly the worst/best place to begin, because it is where the PDP11 ->
>> unix transition takes place. When Lions talks about it, it's clear that he's
>> speaking from the unix side of things with enough PDP to orient a denizen of
>> the times, but not a techie from the future who is ot familiar with stuff
>> like core, I/O regions of memory, or severe hardware limitations. Having
>> struggled to parse every sentence along the way, I've made the journey from
>> the processor handbook - where I found a typo in the 11/40 version... it
>> says:
>> 
>>     Certain memory locations have been reserved by the system for inter·
>>     rupt and trap handling, processor stacks, general registers, and
>> peripheral
>>     device registers. K.ernel virtual addresses from 0 to 370, are always
>> re-
>>     served and those to 777, are reserved on large system configurations for
>>     traps and interrupt handling. The top 4,096 word addresses (from
>>     770000, up) have been reserved for general registers and peripheral
>>     devices.
>> 
>> But, after a couple of hours of head scratching it dawned on me that
>> 770000-777777 was only 2K words and couldn't possibly be right, 760000 is
>> the correct number. Which is click 7600, which is what's loaded into KIPAR7,
>> which the m40 assist maps as IO. Which is properly described in the 1976
>> 11/04/34/45/44 version as:
>> 
>>     If the Memory Management option is not used, an octal address be-
>>     tween 160 000 and 177 777 is interpreted as 760 000 to 777 777. That
>>     is, if bit 15, 14 and 13 are 1 's, then bits 17 and 16 (the extended ad-
>>     dress bits) are considered to be 1's, which relocates the last 4K words.
>>     (8K bytes) to become the highest location accessed by the UNIBUS.
>> 
>> Then on into the peripherals book, the memory management options book, and
>> the v6 manual. In addition, whereas previously, I ignored the source code,
>> now I find it invaluable. Where it says _end is some linker thing (I
>> originally read it as a pseudo op, but it's more something the loader adds).
>> I just pulled up the source, figured out it adds it to the binary if it's
>> referenced in code and that it refers to the boundary of the image (one past
>> the last byte) or in the "as" documentation where Dennis say it's a rather
>> ordinary 2 pass assembler with no macros. I no longer take this as gospel,
>> it's off to the as source where it turns out it's anything but ordinary, not
>> really a two pass assembler (two programs, one that builds a very nice
>> compact representation and the other that takes two passes)  and it trades
>> an insane amount of language affordance for macros... heck it'll even let
>> you define your own assembly instructions :).
>> 
>> It's the little things :).
>> 
>> Will
>> 
>>> On 7/28/26 9:07 PM, Clem Cole via TUHS wrote:
>>> 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
>>>>