Rather than increase subject drift on a thread I started
"UNIX on (not quite bare) System/370", here's a new thread.
Since the TUHS archive seems to now include documentation,
I decided to take a look and see if the earliest UNIX manual I have
is in the archive:
It was given to me by a friend at Stevens Tech in Hoboken NJ (c. 1980)
who had graduated, and worked for AT&T.
It's hole punched for a four ring binder
(I found an unused Bell System Project Telstar binder to put it in).
The cover page has:
Upper left corner:
Bell Telephone Laboratories Incorperated
PROGRAM APPLICATION INSTRUCTION
Upper right corner:
PA-1C300-01
Section 1
Issue 1, January 1976
AT&TCo SPCS
Center:
UNIX PROGRAMMER'S MANUAL
Program Generic PG-1C300 Issue 2
Published by the UNIX Support Group
January, 1976
The preface starts with:
This document is published as part of the UNIX Operating System Program Generic,
PG-1C300 Issue 2. The development of the Program Generic is the result of the
efforts of the members of the UNIX Support Group, supervised by J.F. Maranzano
and composed of: R. B. Brant, J. Feder, C. D. Perez. T. M. Raleigh, R. E. Swift,
G. C. Vogel and I. A. Winheim.
and ends with
For corrections and comments please contact C. D. Perez, MH 2C-423, Extension
6041.
Not knowing who else I could ask, I brought it to a Boston Usenix (in
the 90's or oughts), and asked DMR if he could identify it. He said
it was an early supported UNIX, and he signed the preface page for me.
The manual has sections I through VIII; all manual pages start with page -1-
I found https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_ja…
with cover page:
UNIX PROGRAM DESCRIPTION
Program Generic PG-1C300 Issue 2
Published by the UNIX Support Group
January 1976
contents:
NUMBER ISSUE TITLE
PD-1C301-01 1 Operating System
PD-1C302-01 1 Device Drivers Section 1
PD-1C303-01 1 Device Drivers Section 2
And consists of descriptions of kernel functions.
So it seems likely that my manual is a companion to that.
I have a Brother printer/scanner, but the paper is fragile, so unless
it's of immediate and burning value to someone, it's unlikely to rise
to the top of my ever-static list of documents to scan....
But if someone has specific questions I can look up, let me know....
I’m re-reading Brian Kernighan’s book on Early Unix (‘Unix: A History & Memoir’)
and he mentions the (on disk) documentation that came with Unix - something that made it stand out, even for some decades.
Doug McIlroy has commented on v2-v3 (1972-73?) being an extremely productive year for Ken & Dennis.
But as well, they wrote papers and man pages, probably more.
I’ve never heard anyone mention keyboard skills with the people of the CSRC - doesn’t anyone know?
There’s at least one Internet meme that highly productive coders necessarily have good keyboard skills,
which leads to also producing documentation or, at least, not avoiding it entirely, as often happens commercially.
Underlying this is something I once caught as a random comment:
The commonality of skills between Writing & Coding.
Does anyone has any good refs for this crossover?
Is it a real effect or a biased view.
That great programmers are also “good writers”:
takes time & focus, clarity of vision, deliberate intent and many revisions, chopping away the cruft that’s isn’t “the thing” and “polishing”, not rushing it out the door.
Ken is famous for his brevity and succinct statements.
Not sure if that’s a personal preference, a mastered skill or “economy in everything”.
steve j
=========
A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986
M.D. McIlroy
<https://www.cs.dartmouth.edu/~doug/reader.pdf>
<https://archive.org/details/a_research_unix_reader/page/n13/mode/2up>
pg 10
3.4. Languages
CC (v2 page 52)
V2 saw a burst of languages:
a new TMG,
a B that worked in both core-resident and software-paged versions,
the completion of Fortran IV (Thompson and Ritchie), and
Ritchie's first C, conceived as B with data types.
In that furiously productive year Thompson and Ritchie together
wrote and debugged about
100,000 lines of production code.
=========
Programming's Dirtiest Little Secret
Wednesday, September 10, 2008
<http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret…>
It's just simple arithmetic. If you spend more time hammering out code, then in order to keep up, you need to spend less time doing something else.
But when it comes to programming, there are only so many things you can sacrifice!
You can cut down on your documentation.
You can cut down on commenting your code.
You can cut down on email conversations and
participation in online discussions, preferring group discussions and hallway conversations.
And... well, that's about it.
So guess what non-touch-typists sacrifice?
All of it, man.
They sacrifice all of it.
Touch typists can spot an illtyperate programmer from a mile away.
They don't even have to be in the same room.
For starters, non-typists are almost invisible.
They don't leave a footprint in our online community.
=========
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate?
My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code.
Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()” calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s.
Any other notable work in this area prior to 1985?
How was the SMP implementation in SVr3 judged back in its day?
Paul
Hi folks, sharing another project that I've been tinkering on for a little bit since I like having a lot of irons in the fire: https://gitlab.com/segaloco/v2src
After the link is a repository which over time will be accumulating the results of disassembly and analysis of files found in the s2-bits.tar.gz file in the archive. Details of my process are contained in the repository's readme. The short of it is I'm disassembling the binaries one by one, and where possible am comparing them with known sources to massage these into a pretty close restoration of the original sources.
A few discoveries I've made in the process thus far:
- These binaries appear to represent a version between the first and second editions. The binaries themselves are a mix of "naked" binaries as well as V1 and V2 a.out formats. Where it matters, things are much closer in character to V2 than V1.
- All section 1 content that would be gone by V2 is removed here. Curiously, mount(1), type(1), and umount(1) which are in both V1 and V2 are absent from the s2-bits.
- The sources marked "V2" in the UNIX source tree may be a bit closer in character to V3. Notable examples are that, while string references to /etc/uids remain, all data references have been updated to /etc/passwd, and several mathematical operations in the disassembled binaries map to KE-11 Extended Arithemtic Element registers where in the sources labeled "V2" in the tree have instead shifted to doing these calculations differently, presumably as these sources target the 11/45, not the 11/20. Additionally, the cat.s in "V2" on the tree contains the '-' stdin option, which was first documented in V3. The most likely story is that they're somewhere between, just like the s2-bits are between V1 and V2, but all of these observed differences thus far have aligned the sources with their descriptions in the third edition manual.
Anywho, as usual, if anyone spots anything amiss or that could be done better, happy to accept contributions, or fork it and tinker away. Also, if anyone has already done this, speak up and tell me now so I don't double up on something so involved =P
- Matt G.
> From: Paul Ruizendaal
> something like a boot rom only became the norm in the late
> 70's. Before that, one keyed in two dozen words with a tiny program to
> load the first boot stage.
A little wrong on that date. Even the PDP-11/20 (the first -11) had a boot
ROM:
https://gunkies.org/wiki/BM792_ROM
which appreared in mid-1971 (about a year after the release of the /20). DEC
sold them pre-programmed, but one could 'program' one onself, if one wanted -
with a soldering iron! (Check out the image! I actually did that to one that
I was given, that had been eviscerated by someone.) From then on (follow the
category link), the rest used PROM chips.
> From: Warner Losh
> Oftentimes, the interrupt vector was in the lowest core addresses
It's worth remembering that in the early period, that restriction to low
addresses was built into the hardware (in an amusing way :-).
Take the DL11:
https://gunkies.org/wiki/DL11_asynchronous_serial_line_interface
which was sort of mandatory as the 'console' serial interface on most early
-11's (until the DL11-W appeared; more on its big improvement in a second).
It set the interrupt vector with _jumpers_. (You want to change the interrupt
vector? Dig out your soldering iron! :-) There were only 6 jumpers - one each
for address bits 3 through 8. So the largest vector you could set was 0770.
The DL11-W was a big step forward - it replaced the jumpers with a DIP
switch! :-) Still only six bits, though. :-)
Noel
Hi Matt,
I’ve responded on list about the early unix development process as I understand it, but I want to avoid discussing things that are not directly related to the history of Unix. Hence this PM as well.
> Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations.
I have a similar interest, working with early Unix and modern RiscV hardware for a compare and contrast experience.
- My development targets are (i) an FPGA based RV32 SoC implementation, (ii) a Sipeed D1 RV64GC board and shortly (iii) a Pine64 Pinetab-V.
- My software targets are: (a) xv6-rv, (b) SysIII, (c) Linux, (d) experiments around SysIII
Linux is for me a secondary target, just for comparison and to see if ideas are “Linux capable”. I’m not overly interested in Arm at the moment.
My ideas are still evolving, but currently more or less along the below lines:
- Boot rom loads SPL, this is custom in each case and set by the SoC's designers.
- SPL initialises DRAM system and loads next stage. Unfortunately, this too would seem to be quite system specific, but the BSP should provide the baseline for this. As BSP’s are often a mess, milage may vary.
- The next stage is a hybrid of BBL, OpenSBI and Virtio. The idea is to provide a standard abstraction layer that all of my software targets can work with. This idea is used for the FPGA target and allows booting a Linux kernel with just the generic Virtio device drivers (so far just disk and console).
- The last layer is the classical OS layer. If I get it right, each OS can run on all h/w targets without customisation.
At the moment I’m playing with USB, and how that might layer into the structure of V7, SysIII or 8th Edition -- and also the above.
> Date: Mon, 10 Apr 2023 18:27:51 +0000
> From: segaloco
> ... or was there no single guiding principle and each machine came up, at that level at least, in a relative vacuum, with only the machine interface to UNIX being the guiding principle?
I stumbled into the same question last year, when doing my SysIII to RV64 port. I managed to turn that into a somewhat chaotic discussion, mixing old and new, and history with ideas. From that chaotic discussion I got the impression that it was indeed mostly ad hoc. In context, hardware was much easier to boot and drive back then -- it probably was not seen as complex enough to warrant much research into layering and abstraction.
Also bear in mind that something like a boot rom only became the norm in the late 70’s. Before that, one keyed in two dozen words with a tiny program to load the first boot stage.
That said, there is an implicit layering in v7 and beyond:
- “low.s" does hardware setup, incl. such stuff as setting up interrupt tables. As this is closely tied to the hardware, it would have been a custom job in each case.
- “mch.s” (later also mch.c) has the basic routines that are hardware dependent (switching stacks, changing priority levels and modes, etc.). It also has emulation for ‘missing’ instructions, such as floating point ops where this is not available in hardware. Same as above, I think. Maybe h/w related memory protection operations should live here as well, but the hardware was still quite divergent in this area in the 70’s and early 80’s.
- low-level device drivers live in the ‘dmr’ or (later) ‘io’ directory. Here there is some standardisation, as all device drivers must conform to the (char/block) device switch APIs. It seems to me that most of these drivers were written by taking one that was similar to what needed to be written and to start from there. Maybe this is still how it works in Linux today.
- To the extent that there is such a thing as 'high-level device drivers’ in early Unix, the structure is less clearly visible. The file system (and there was only one at the time of v7) is placed between the block device switch and the mount table so to speak. This was structured enough that splicing in other file systems seems to have been fairly easy in the early 80’s (the splicing in, not the writing of the file system itself, of course). Starting with 8th edition, the ‘file system switch’ created a clear API for multiple file systems. Arguably, the ‘tty’ subsystem is also a ‘high-level device driver’, but this one lives as custom code together with the serial port device drivers. Also in 8th Edition, ‘streams' were introduced. One could think of this as a structured approach to high-level device drivers for character mode devices, incl. the ’tty’ subsystem.
- I don’t think there was ever anything in early Unix that merged ’streams’ and the 'file system switch' into a single abstraction (but maybe 9P did?).
> Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations.
I have a similar interest, but to avoid the same chaos as I created before, I’ll respond to this with a pm.
> Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals?
The Bell Labs publication department at Whippany did the physical
design for the bound versions of the Research Unix manual--from v7 as
a trade brook through v10, also a trade book.. They did the cover
designs for v8-v10 in house. I am not sure whether they did the v7
cover, farmed it out, or left it up to Holt Rinehart. Whippany handled
the printing of v8 and v9. Saunders College Publishing did it for v10.
Unfortunately, I do not remember whom I dealt with in Whippany, and my
records of the interactions are long gone.
Doug
Good evening, I'd like to share a listing I've taken of the various extra pages present in the BTL version of the SVR2 User's Manual I picked up a little while ago.
https://pastebin.com/18uTzyfS
Like the Release 5.0 BTL version before it, many of the added pages are DIV 452 standard pages for Writer's Workbench as well as the Basic-16/BELLMAC-4/BELLMAC-8 development environments.
To quote the preface:
"This manual was designed through a cooperative effort of the BTL Computer Centers in Division 452. It represents a collection of nearly all the commands that are running on any Computer Center UNIX machine.
...
The header of each manual page identifies the classification of the command along with any machine or site dependencies.
...
Any page marked LOCAL indicates the sites that are running that command.
...
Pages marked DIV 452 STD are from the collection of Computer Center standard commands, and are available on machines administered by Division 452 Computer Centers. The pages that are designated as INTERIM or 5.0 are those commands which are scheduled to be included in a separate WECo software add-on package."
This manual is just sections 1 and 6, presumably 1m, 7, and 8 are in a corresponding administrator's manual and 2, 3, 4, 5 are in a programmer's manual, making SVR2 the start of the user's manual being further subdivided. I seem to recall one or the other of this same issue of manuals show up on eBay at some point, I'm kicking myself for not springing for it at the time, but hopefully one or the other (or both) turn up again to be documented someday.
Additionally included in the above listing is a list of references from various "SEE ALSO" sections throughout the manual, as well as some other odds and ends from the text. Finally, there is a short listing of teach(1) classes as provided by a couple variants of the application.
If any particular page piques an interest, let me know and I can scan it for you, otherwise this one is a ways away on my scan backlog.
- Matt G.
Good day everyone, I'm in search of a bit of esoteric information regarding published UNIX works. Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals?
Some that come to mind:
The alphabet blocks cover of the HRW V7 Manuals
The simple 70's Bell-style cover of the UNIX System III manual
The nice 3B-20 picture on the UNIX 4.1 manual
The grid patterns design on the UNIX System V documentation
The blue "big V" SVR4 manuals (given the time disparity, these could have totally different underpinnings)
Where I'm particularly curious is how these covers were actually set, defined, the image data to print on them stored, formatted, etc. In other words, <???>:troff::covers:manpages where ??? may also represent more than just the specific tools/formats. Anyone have the scoop on the actual raw materials and technologies used for preparing the covers and/or if any of those original assets, in their raw form, would potentially still exist somewhere? To be honest, I am particularly interested in the original, highest fidelity possible image of the 3B-20 from the corresponding manual (https://commons.wikimedia.org/wiki/Category:Unix_Manuals#/media/File:UNIX4.…) but am happy with any info illuminates what went into the actual physical production. Thanks all!
- Matt G.
P.S. If it provides any leads, the closest thing I've found in actual document sources to material related to these aspects of physical publication are the files M.folio and M.tabs here: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/tools
