I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
While it's fresh, I thought I'd share some resources I've found helpful
in learning about the venerable v6 as a relative newb...
Learning Unix V6 in the modern era is an interesting and enormously
educational experience. In the process of using it I have had to learn
how to host it in a simulator (SimH in my case, but there are others),
install it, communicate with it, configure it, build special files for
it, attach devices to it, communicate with the devices attached to it
and to SimH, build a kernel, install the kernel, boot the kernel, work
with a variety of media intended to work with it, extend it, and so on.
In addition, I have had to learn a bit about the PDP-11 (as arguably the
most convenient architecture for learning about V6), about its
architecture, its instruction set, its devices, its memory structure,
and so on.
None of this exploration would have been possible without the excellent
work of Bob Supnik, Mark Pizzolato, and co. on the SimH pdp-11
simulator, the Simh mailing list, Warren Toomey and TUHS for making the
bits available, the TUHS mailing list, PUPS, Bitsavers, and a slew of
readily available documentation and texts including these notables:
Setting Up Unix 6th Edition from the V6 Programmer's Manual
The Unix V6 Programmer's Manual in its entirety
The SimH and SimH PDP-11 Manuals
A large number of blogs with SimH specific V6 installation logs
The V6 Source Code and man pages (don't forget to install man - the 1bsd
version works, and is superior)!
The DEC PDP-11/05-10-35-40 1973 Handbook (the 11/40 handbook is not as
detailed with respect to memory management)
Lions's Commentary on the Sixth Edition source code
Now that I'm over the beginner's hump, so to speak, I'm exploring things
differently and I thought I'd share some resources that I am currently
finding useful and interesting in my explorations...
To bone up on assembly language, Lions's commentary is exceptionally
helpful in explaining assembly as it is implemented in V6. The manual
itself is really thin, and the source is a bit cryptic, for the
newcomer. Lions explains the idioms used in the main source of V6.
However, without a background in assembly language, Lions is pretty
meaningless, so I went looking for something that was PDP specific that
would bridge the gap and help me understand Lions's words. I found a
number of texts that were really good. Most require a working RT11
instance to actually try out the coding examples and do the exercises
(SimH and Bitsavers to the rescue):
Arthur Gill - Machine and Assembly Language Programming of the Pdp-11
Charles A. Kapps and Robert L. Stafford - Assembly Language for the PDP-11
Glenn H. MacEwan - Introduction to Computer Systems: Using the PDP-11
James F. Peters - The Digital Way: Macro-11 Assembler Programming (PDP-11)
Michael G. Schneider - The Principles of Computer Organization: With
Assembly Language Programming for the PDP-11
PDP-11 Processor Handbook (pretty much any edition)
Thomas A. Frank - Introduction to the PDP-11 and its Assembly Language
All of these are useable with a running RT11 instance. But, I think the
Peters and Frank books are the standouts. Peters because all of the
exercises that I have tried (dozens) have worked as printed and Frank
because he is rigorous in his treatment of the subject and builds up
from digital logic all the way through program execution. Frank is an
excellent complement to Lions work because he explains the details that
To learn about digital logic, and a special thanks to Warren for his
work on Crazy Small CPU, I have been introduced to logisim. It is a
great playground for exploring digital logic. I had no idea that a
sketchpad for digital logic simulation was available and accessible to
the layperson. Logisim development stopped around 2014 and while there
are a number of successors out there, I am using logisim-evolution:
The rabbit trails never seem to end... in order to learn how to use
logisim, I went through the excellent tutorial and then went looking for
a book of experiments in digital logic and found:
digital computer lab workbook from 1969
digital equipment corporation computer lab teacher's guide from 1968
These two are useable with very little modification as a source of
digital logic exercises that work great with logisim and are related to
the architectural lineage of the PDP-11.
These resources fit together nicely in my pursuit to better understand
digital logic, the pdp-11, assembly language, and unix v6. In sum:
Source code for v6 for what really is supposed to happen in v6 operation
Lions for understanding Unix V6 sources and for unix assembly language
PDP-11 Hanbook for quick reference on PDP-11 assembly language
Frank for assembly language details and for details on digital logic and
its relationship to the PDP-11 architecture.
Logisim to test logic constructs
The digital lab workbook for practice with digital logic
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote:
> Larry McVoy <lm(a)mcvoy.com> wrote:
> |On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
> |> 1977 marks my entry into the world of UNIX. I've always stated there was
> |> only one person who truly understood nroff and he was dead.
> |> I mourn the fact that of all the UNIX greats I've met, I missed out on
> |> Ossanna.
> |I think one could argue that James Clark has a pretty good handle on
> |roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).
> And Werner Lemberg, who carried the torch for the last almost two
> decades. He brought in some really great improvements, like
> arguments for strings, which allows to write pretty much TeX like
> a.k.a. inline if you want to (as in "this is \*[I talic] text").
Yep. James exited stage left and Werner stepped in. I mean no disrespect
to anyone, I was just saying that James has a really good handle on roff,
he redid it all. I admire him for doing so (even though I curse the fact
that he did it in C++).
Was Unix ever ported to a PDP8, or any other 12 bit environment, for
that matter? If not, why not? My understanding, such as it is, is that
Unix was created on the PDP7 - btw, thank you very much, Ken Thompson,
you definitely changed my world :), which is an 18bit machine, and that
it soon found its first real home on the 16 bit PDP11 series of machines
(an 11/20), and from there, ever upward or at least ever onward. I'm
curious about it for historical reasons, of course, but also because
I've been messing around in the PDP8 emulation world and enjoying the
excursion into simplified ISA and memory architectures.
So tape I can see being more weird, but isn't raw disk just "don't put it
in buffer cache"?
>From what I've been able to gather early tape in Unix was dicey, something
about the driver doing seek. Was there more to it than that?
On Tue, Nov 21, 2017 at 02:33:55AM +0000, Clem Cole wrote:
> It???s not so much that they don???t mix, it???s not quite the same. Some
> coprocessor ideas work really well into the Unix I/O model, others don't.
> Raw disk and tape I/O ala a PDP11 or VAX for instance is not easy on an
> IBM channel controller or a CDC PPU.
> On Mon, Nov 20, 2017 at 6:45 PM Larry McVoy <lm(a)mcvoy.com> wrote:
> > On Mon, Nov 20, 2017 at 06:43:28PM -0500, Ron Natalie wrote:
> > >
> > >
> > > > I get that PDP-11 and VAX used memory mapped I/O but was that somehow
> > > exposed above the device driver layer? If so, I missed that, because I
> > had
> > > no conceptual or technical problem with talking to an I/O
> > >
> > > > channel, it was pretty easy. And I suck at writing drivers.
> > >
> > > There's nothing that restricts a device driver to memory mapped I/O.
> > You
> > > do what ever you have to do to initiate the I/O. Even the x86's
> > originally
> > > used special instructions to start the I/O (in/out). The DENELCOR HEP
> > > supercomputer (we did this port around 1983) we had to bounce I/O
> > requests
> > > off a separate I/O processor different from where the kernel was running.
> > > Similar constucts were used on other machines.
> > Yeah, that's what I thought. But other people were saying that I/O
> > processors and Unix didn't mix. I don't get that, seems like whatever
> > the model is is hidden under the driver, that's the whole point of the
> > driver design is it not?
> Sent from a handheld expect more typos than usual
Larry McVoy lm at mcvoy.comhttp://www.mcvoy.com/lm
> From: Charles Anthony
> Entry points are usually defined as "foo$bar", where "foo" is the
> segment name, and "bar" an entry point in the segment symbol table. I
> believe that the degerate case of "foo$" is treated as "foo$foo" by the
So I'm curious about how this, and additional names, interact. (For those who
aren't familiar with Multics, a segment [file, sort of] can have multiple
names. This is sort of like 'hard links' in Unix, except that in Multics one
name, the "primary name" is very slightly preeminent. See here:
page 2-5, for more, if you're interested.)
So if I have a segment with primary name 'foo', and additional names 'bar' and
'zap', and I say 'zap' to the Multics shell, I assume it does a call to
zap$zap, which finds the segment with the primary name 'foo', and calls the
'zap' entry therein?
> Multics rulez; UNIX droolz
Dude, you clearly have Very Large brass ones to send that to this list! :-)
Early on, when multics was understood to have
one big, segemented address space, it was expected
that PL/I name qualification ($) would serve to address
segments. I do not know whether that idea was
My favorite reduction to absurdity was /bin/true. Someone decided we
needed shell commands for true and false. Easy enough to add a script that
said "exit 0" or exit 1" as its only line.
Then someone realized that the "exit 0" in /bin true was superfluous, the
default return was 0. /bin/true turned into an empty, yet executable, file.
Then the lawyers got involved. We got a version of a packaged UNIX (I
think it was Interactive Systems). Every shell script got twelve lines of
copyright/license boilerplate. Including /bin true.
The file had nothing but useless comment in it.
> Multics had some kind of `attach' and `detach' of I/O streams, well
> known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go
> with it meant `>' was earmarked early on.
According to "The Evolution of the Unix Timesharing System", full path names
arrived later than I/O redirection, so by they time they needed a separator,
'>' and '<' were gone. '/' also has the advantage of being a non-shift
PS: Re-reading that, I see that early Unix did not have an exec() call (as I
was just discussing); it was done in user mode, with normal read and write