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.)
We gained John von Neumann on this day in 1903, and if you haven't heard
of him then you are barely human... As computer science goes, he's right
up there with Alan Turing. There is speculation that he knew of Babbage's
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
I've just had an interesting experience, explaining C header files to
a nephew programmer who didn't understand them. I pointed him in the
direction of Minix as an example of a small well-engineered system
which would display their use.
Which raised the question: when did header files come into use? Who
was the first to use header files to store common system-wide or
application-wide data definitions? Was it used in any languages prior
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
> From: Dave Horsfall <dave(a)horsfall.org>
> the ARPAnet got converted from NCP to TCP/IP in 1983; ... have a more
> precise date?
No, it was Jan 1.
It wasn't so much a 'conversion', as that was the date on which, except for a
few sites which got special _temporary_ dispensation to finish their
preparations, support for NCP was turned off for most ARPANET hosts. Prior to
that date, most hosts on the ARPANET had been running both, and after that,
only TCP worked. (Non-ARPANET hosts on the then-nascent Internet had always
only been using TCP before that date, of course.)
Some interesting historical stuff today...
We lost Rear Admiral Dr. Grace Hopper USN (Retd) in 1992; there's not much
more than can be said about her, but I will mention that she received
(posthumously) the Presidential Medal of Honor in 2016.
As every Unix geek knows, today is the anniversary of The Epoch[tm] back
in 1970, and at least one nosey web site thinks that that is my birthdate
And according to my notes, the ARPAnet got converted from NCP to TCP/IP in
1983; do any greybeards here have a more precise date?
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
On Fri, Dec 29, 2017 at 04:04:01AM -0700, Kevin Bowling wrote:
> Alpha generally maintained integer/ALU and clockspeed leadership for
> most of the '90s
Wow, that first graph is the most misleading graph on CPU performance
I've ever seen. Ever.
So from 1993 to 2000 the only CPUs released were Alphas?
That era was when I was busy measuring performance across cpus and
operating systems and I don't ever remember any processor being a
factor of 2 better than its peers. And maybe I missed it, I only
owned a couple of alpha systems, but I never saw an Alpha that was
a game changer. Alpha was cool but it was too little, too late to
In that time period, even more so now, you had to be 2x better to get
a customer to switch to your platform.
2x more reliable
Do one of those and people would consider switching platforms. Less than
that was really tough and it was always, so far as I remember, less than
that. SMP might be an exception but we went through that whole learning
process of "well, we advertised symmetric but when we said that what we
really meant was you should lock your processes down to a processor
because caches turn out to matter". So in theory, N processors were N
times faster than 1 but in practice not so much.
I was very involved in performance work and cpu architecture and I'd love
to be able to claim that we had a 2x faster CPU than someone else but we
didn't, not at Sun and not at SGI.
It sort of make sense that there weren't huge gaps, everyone was more or
less using the same sized transistors, the same dram, the same caches.
There were variations, Intel had/has the biggest and most advanced
foundries but IBM would push the state of the art, etc. But I don't
remember anyone ever coming out with a chip that was 2x faster. I
suspect you can find one where chip A is introduced at the end of chip
B's lifespan and A == 2*B but wait a few month's and B gets replaced
and A == .9*C.
Can anyone point to a 2x faster than it's current peers chip introduction?
Am I just not remembering one or is that not a thing?
A bit off the PDPs, but to do a minor correction on mail below
The commercial version of 'UNIX' on Alpha was maybe first called
Digital Unix OSF/1, but quickly changed to Digital Unix at least with
v3 and v4.0 (A - G). From there we had a 'break' which only in part
was due to take over by Compaq and we had Tru64 UNIX v5.1A and V5.1B.
The V5.1B saw updates till B-6.
As for the Digital C compiler, I'm still using
DTCCMPLR650 installed Compaq C Version 6.5 for Compaq Tru64 UNIX Systems
When I get some old source (some even developed on SCO UNIX 3.2V4.2) I
like to run it through all compiler /OS-es I got handy. With the
Compaq C compiler and HP-UX ANSI C I mostly get pages of warning and a
few errors. By the time I 'corrected' what I think is relevant some
nasty coredumps tend to disappear :-)
Compile for a better 2018,
>Date: Fri, 29 Dec 2017 21:30:11 -0500.
>From: Paul Winalski <paul.winalski(a)gmail.com>
>To: Ron Natalie <ron(a)ronnatalie.com>
>Cc: TUHS main list <tuhs(a)minnie.tuhs.org>
>Subject: Re: [TUHS] Why did PDPs become so popular?
Content-Type: text/plain; charset="UTF-8"
>On 12/29/17, Ron Natalie <ron(a)ronnatalie.com> wrote:
> The Alpha was hot
> stuff for about nine months. Ran OSF/1 formerly DigitalUnix formerly
>Digital UNIX for the VAX was indeed derived from OSF/1. The port to
>Alpha was called Tru64 UNIX.
>Tru64 UNIX was initially a pure 64-bit system, with no provision for
>building or running 32-bit program images. This turned out to be a
>mistake . DEC found out that a lot of ISVs had code that implicitly
>"knew" that sizeof() a pointer was the same as sizeof(int) was the
>same as 4 bytes. Tru64 was forced to implement a 32-bit compatibility
>There was also a problem with the C compiler initially developed at
>DECwest in Seattle. It supported ONLY ANSI standard C and issued
>fatal errors for violations/extensions of the standard. We (DEC
>mainstream compiler group) called it the Rush Limbaugh
>compiler--extremely conservative, and you can't argue with it.
Warning: off-topic info
> I was told once that McIlroy and Morris invented macro instructions
> for assembly language. And certainly they wrote the definitive
> paper on macros, with, as I recall, something like 10 decisions you
> needed to make about a macro processor and you could generate 1024
> different macro systems that way. I wonder if that ever got
The suggestion that I invented macros can also be found on-line, but
it's not true. I learned of macros in 1957 or before. GE had added
a basic macro capability to an assembler; I don't know whether they
invented the idea or borrowed it. In 1959 George Mealy suggested
that Bell Labs install a similar facility in SAP (SHARE assembly
program). Doug Eastwood wrote the definition part and I handled
Vic Vyssotsky later asked whether a macro could define a macro--a
neat idea that was obviously useful. When we went to demonstrate
it, we were chagrinned that it didn't work: definition happening
during expansion resulted in colliding calls to a low-level
string-handling subroutine that was not re-entrant. Once that
was fixed, Steve Johnson (as a high-school intern!) observed
that it allowed the macro table to serve as an addressable
memory, for which the store and load operations were MOP
(macro define) and MAC (macro call).
Probably before Steve's bright insight, Eastwood had folded
the separate macro table into the opcode table, and I had
implemented conditional assembly, iteration over a list, and
automatic generation of symbols. These features yielded
a clean Turing-complete language-extension mechanism. I
believe we were the first to achieve this power via macros.
However, with GPM, Christopher Strachey showed you don't need
conditionals; the ability to generate new macro names is
enough. It's conceivable, but unlikely, that this trick
could be done with earlier macro mechanisms.
As for publication, our macroprocessor inspired my CACM
paper, "Macro nstruction extension of compiler languages",
but the note that Steve remembers circulated only in the
Labs. A nontrivial example of our original macros in
action--a Turing machine simulator that ran completely within
the assembler--was reproduced in Peter Wegner's programming
book, so confusingly described that I am glad not to have
been acknowledged as the original author.
> From: Paul Winalski
> Lack of marketing skill eventually caught up to DEC by the late 1980s
> and was a principal reason for its downfall.
I got the impression that fundamentally, DEC's engineering 'corporate culture'
was the biggest problem; it wasn't suited to the commodity world of computing,
and it couldn't change fast enough. (DEC had always provided very well built
gear, lots of engineering documentation, etc, etc.)
I dunno, maybe my perception is wrong? There's a book about DEC's failure:
Edgar H. Schein, "DEC is Dead, Long Live DEC", Berett-Koehler, San
which probably has some good thoughts. Also:
Clayton M. Christensen, "The Innovator's Dilemma: When New Technologies
Cause Great Firms to Fail", Harvard Business School, Boston, 1997
briefly mentions DEC.