From tuhs at tuhs.org Thu Jan 1 01:26:50 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Wed, 31 Dec 2025 16:26:50 +0100 Subject: [TUHS] unix v4 tape found In-Reply-To: References: Message-ID: And i gave a lightning talk at 39c3: https://media.ccc.de/v/39c3-lightning-talks-tag-3#t=6345 aap On 20/12/25, Angelo Papenhoff via TUHS wrote: > It's booting too! added info to the readme. > > =uboot > k > unix > > login: root > # ls > bin > dev > etc > lib > mnt > tmp > unix > usr > # > > > aap > > On 20/12/25, Angelo Papenhoff via TUHS wrote: > > I extracted it: http://squoze.net/UNIX/v4/ > > > > aap > > > > On 19/12/25, Matt Day via TUHS wrote: > > > Rob Ricci updated today on his Mastodon page: > > > > The attempt to read the UNIX V4 tape is underway! > > > > I'm told "there is data" but I honestly don't know what that means yet. > > > -- https://discuss.systems/@ricci/115747843169814700 > > > The process is being filmed by a TV news crew and some footage is already > > > available. > > > > > > > > > On Thu, Nov 6, 2025 at 3:42 PM Rob Pike via TUHS wrote: > > > > > > > https://phanpy.social/#/hachyderm.io/s/115504720323483804 > > > > > > > > From mastodon: > > > > > > > > > > > > Rob Ricci > > > > ricci at discuss.systems > > > > > > > > While cleaning a storage room, our staff found this tape containing #UNIX > > > > v4 from Bell Labs, circa 1973 > > > > > > > > Apparently no other complete copies are known to exist: > > > > gunkies.org/wiki/UNIX_Fourth_E > > > > > > > > > > > > We have arranged to deliver it to the Computer History Museum > > > > From tuhs at tuhs.org Thu Jan 1 01:33:06 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Wed, 31 Dec 2025 08:33:06 -0700 Subject: [TUHS] unix v4 tape found In-Reply-To: References: Message-ID: Sweet talk. Thanks for sharing. Warner On Wed, Dec 31, 2025, 8:27 AM Angelo Papenhoff via TUHS wrote: > And i gave a lightning talk at 39c3: > https://media.ccc.de/v/39c3-lightning-talks-tag-3#t=6345 > > aap > > On 20/12/25, Angelo Papenhoff via TUHS wrote: > > It's booting too! added info to the readme. > > > > =uboot > > k > > unix > > > > login: root > > # ls > > bin > > dev > > etc > > lib > > mnt > > tmp > > unix > > usr > > # > > > > > > aap > > > > On 20/12/25, Angelo Papenhoff via TUHS wrote: > > > I extracted it: http://squoze.net/UNIX/v4/ > > > > > > aap > > > > > > On 19/12/25, Matt Day via TUHS wrote: > > > > Rob Ricci updated today on his Mastodon page: > > > > > The attempt to read the UNIX V4 tape is underway! > > > > > I'm told "there is data" but I honestly don't know what that means > yet. > > > > -- https://discuss.systems/@ricci/115747843169814700 > > > > The process is being filmed by a TV news crew and some footage is > already > > > > available. > > > > > > > > > > > > On Thu, Nov 6, 2025 at 3:42 PM Rob Pike via TUHS > wrote: > > > > > > > > > https://phanpy.social/#/hachyderm.io/s/115504720323483804 > > > > > > > > > > From mastodon: > > > > > > > > > > > > > > > Rob Ricci > > > > > ricci at discuss.systems > > > > > > > > > > While cleaning a storage room, our staff found this tape > containing #UNIX > > > > > v4 from Bell Labs, circa 1973 > > > > > > > > > > Apparently no other complete copies are known to exist: > > > > > gunkies.org/wiki/UNIX_Fourth_E > > > > > > > > > > > > > > > We have arranged to deliver it to the Computer History Museum > > > > > > From tuhs at tuhs.org Thu Jan 1 08:01:38 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 31 Dec 2025 22:01:38 +0000 Subject: [TUHS] unix v4 tape found In-Reply-To: References: Message-ID: <3Pz-Il9LcgBA9p70FPQFM2N8dGdwdQ8LH2PtHbHf5-RvaT2JjQ-LmNcey7neDQuJxrWOedl6P4nTkSSLO6mhUQcsDzFPAIXIRM-0i5qu00Y=@protonmail.ch> Great talk, Angelo, Shame it had to be only 5 minutes and not 5 hours. That would freak me out, going up on stage and knowing I only had 300 seconds to make some kind of sense. Thank you also for the links, at the end of your talk, they were super useful. Frohes neues Jahr! / Joyous New Year to everyone! Cameron -------- Original Message -------- On Wednesday, 12/31/25 at 15:27 Angelo Papenhoff via TUHS wrote: And i gave a lightning talk at 39c3: https://media.ccc.de/v/39c3-lightning-talks-tag-3#t=6345 aap From tuhs at tuhs.org Fri Jan 2 09:27:34 2026 From: tuhs at tuhs.org (=?utf-8?q?Martin_Schr=C3=B6der_via_TUHS?=) Date: Fri, 2 Jan 2026 00:27:34 +0100 Subject: [TUHS] HP-UX is EOL Message-ID: Hi, happy new year. HP-UX went EOL on 2025-12-31: https://www.osnews.com/story/144094/hp-ux-hits-end-of-life-today-and-im-sad/ Best Martin From tuhs at tuhs.org Fri Jan 2 19:14:01 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Fri, 2 Jan 2026 20:14:01 +1100 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: On Sun, Dec 28, 2025 at 10:38:37PM +0000, Thalia Archibald via TUHS wrote: > On Dec 28, 2025, at 14:12, segaloco via TUHS wrote: > > First image is V6 (+BTL Lions Commentary) > > I thought that Lions’ Commentary wasn’t distributed after BTL took over distribution? > Do you know whether there’s a scan of that version anywhere? > > The BTL takeover was announced in the March 1978 issue of ;login:. > https://archive.org/details/login_march-1978/page/n1/mode/1up > > Thalia Licensees were allowed to have one copy from BTL. https://archive.org/details/login_nov84_issue/page/n25/mode/1up https://www.tuhs.org/Usenet/comp.unix.wizards/1981-June/000459.html https://www.tuhs.org/Usenet/comp.unix.wizards/1986-January/015591.html From tuhs at tuhs.org Sat Jan 3 04:39:41 2026 From: tuhs at tuhs.org (David Barto via TUHS) Date: Fri, 2 Jan 2026 10:39:41 -0800 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: References: Message-ID: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> May I suggest that the following is a good read for V6 internals. Without source, and a well written description of functions. David https://archive.org/details/unix_program_description_jan_1976/page/n5/mode/2up UNIX Program Description : Bell Telephone Laboratiories, Incorporated : Free Download, Borrow, and Streaming : Internet Archive archive.org > On Jan 2, 2026, at 1:14 AM, Jonathan Gray via TUHS wrote: > > On Sun, Dec 28, 2025 at 10:38:37PM +0000, Thalia Archibald via TUHS wrote: >> On Dec 28, 2025, at 14:12, segaloco via TUHS wrote: >>> First image is V6 (+BTL Lions Commentary) >> >> I thought that Lions’ Commentary wasn’t distributed after BTL took over distribution? >> Do you know whether there’s a scan of that version anywhere? >> >> The BTL takeover was announced in the March 1978 issue of ;login:. >> https://archive.org/details/login_march-1978/page/n1/mode/1up >> >> Thalia > > Licensees were allowed to have one copy from BTL. > > https://archive.org/details/login_nov84_issue/page/n25/mode/1up > https://www.tuhs.org/Usenet/comp.unix.wizards/1981-June/000459.html > https://www.tuhs.org/Usenet/comp.unix.wizards/1986-January/015591.html From tuhs at tuhs.org Sat Jan 3 04:52:50 2026 From: tuhs at tuhs.org (Rik Farrow via TUHS) Date: Fri, 2 Jan 2026 11:52:50 -0700 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> Message-ID: Thanks, that's actually very interesting. One the second page, update() is described as including a lock to prevent it being called a second time before the first call is completed. That explained to me the lore I picked up at UC Berkeley about typing "sync;sync". I wondered why it was necessary to use sync twice, and the answer is that it's not: the first invocation appears to return immediately but invoked sync the second time waits until the first finishes--so you can tell updating of inodes and superblocks has completed. I'd heard that VAX systems running Unix were slow enough that experienced users could tell the system was becoming unstable and type sync. There was also a 'sync' user account, so typing 'sync' as a username would fire off update(). Rik On Fri, Jan 2, 2026 at 11:40 AM David Barto via TUHS wrote: > May I suggest that the following is a good read for V6 internals. Without > source, and a well written description of functions. > > David > > > https://archive.org/details/unix_program_description_jan_1976/page/n5/mode/2up >  > UNIX Program Description : Bell Telephone Laboratiories, Incorporated : > Free Download, Borrow, and Streaming : Internet Archive > archive.org > > > > On Jan 2, 2026, at 1:14 AM, Jonathan Gray via TUHS > wrote: > > > > On Sun, Dec 28, 2025 at 10:38:37PM +0000, Thalia Archibald via TUHS > wrote: > >> On Dec 28, 2025, at 14:12, segaloco via TUHS wrote: > >>> First image is V6 (+BTL Lions Commentary) > >> > >> I thought that Lions’ Commentary wasn’t distributed after BTL took over > distribution? > >> Do you know whether there’s a scan of that version anywhere? > >> > >> The BTL takeover was announced in the March 1978 issue of ;login:. > >> https://archive.org/details/login_march-1978/page/n1/mode/1up > >> > >> Thalia > > > > Licensees were allowed to have one copy from BTL. > > > > https://archive.org/details/login_nov84_issue/page/n25/mode/1up > > https://www.tuhs.org/Usenet/comp.unix.wizards/1981-June/000459.html > > https://www.tuhs.org/Usenet/comp.unix.wizards/1986-January/015591.html > > From tuhs at tuhs.org Sat Jan 3 05:33:11 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 02 Jan 2026 19:33:11 +0000 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> Message-ID: On Friday, January 2nd, 2026 at 10:53, Rik Farrow via TUHS wrote: > Thanks, that's actually very interesting. One the second page, update() is > described as including a lock to prevent it being called a second time > before the first call is completed. That explained to me the lore I picked > up at UC Berkeley about typing "sync;sync". I wondered why it was necessary > to use sync twice, and the answer is that it's not: the first invocation > appears to return immediately but invoked sync the second time waits until > the first finishes--so you can tell updating of inodes and superblocks has > completed. > > Rik I've seen this sort of thing in plenty of places, an operation that is gated by itself, run it twice in case the gate was closed the first time or otherwise you need to be sure the first one finished. On the NES, this is done to synchronize the PPU chip in software by awaiting v blank twice. The first is actually to erase any potential spurious interrupt flag and the second to then poll knowing you started with the flag down. Is there a name for this? I want to just call this sempahoring but it may be that a binary semaphore is a case of this larger thing. > On Fri, Jan 2, 2026 at 11:40 AM David Barto via TUHS tuhs at tuhs.org wrote: > > > May I suggest that the following is a good read for V6 internals. Without > > source, and a well written description of functions. > > > > David > > > > https://archive.org/details/unix_program_description_jan_1976/page/n5/mode/2up > >  > > UNIX Program Description : Bell Telephone Laboratiories, Incorporated : > > Free Download, Borrow, and Streaming : Internet Archive > > archive.org > > For those following along at home, this specifically describes the USG Program Generic II kernel, so may have slight differences regarding stock V6 (and/or stock PDP-11/45 C kernel ). Does anyone on-list know the providence of this document by the way? The scan edges indicate it came from a comb-bound volume, I'd be curious if these were the only pages, if that volume contained other UNIX stuff, and especially if this implies other comb-binding of manuals at the time. Reason I ask is I seem to recall reading a post here or on a Usenet list by Ted Dolotta I believe detailing that the Release 3.0 manuals got approval to be printed on the same comb-bound stock used for internal phone directories, and that it was the first time USG had "published" a manual so formally. Seeing the comb-binding holes in the scan casts some doubt on this. - Matt G. From tuhs at tuhs.org Sat Jan 3 06:33:51 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 2 Jan 2026 15:33:51 -0500 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> Message-ID: below On Fri, Jan 2, 2026 at 2:33 PM segaloco via TUHS wrote: > ... > > > For those following along at home, this specifically describes the USG > Program Generic II kernel, I believe (as I was told at the time the kernel that Armando Stettner and the late Ted Kowalski worked on at Summit in the Unix Support Group (USG) was supposed to be called UNIX/TS. There is a note I wrote in pencil in my copy, to use this over Lion's in the future. Ted always talked about UNIX/TS as if it were going to be the official thing. > so may have slight differences regarding stock V6 (and/or stock PDP-11/45 > C kernel ). And V7 for that matter. Without looking at it again, my >>memory<< is that this document defines the kernel that Research took back. There was a push tio to unify the different flavors (CB/Unix, PWB, Risner's kernel, et al). USG was chartered by folks fairly high up in the AT&T food chain (similarly to how CSRG was chartered by DARPA); to create and support UNIX for the Bell System at large. I always understood that the action of importing the Summit kernel at that time was that Al Arms was starting the V7 licensing. As I understand it, Dennis did not want to be the "release engineer" for V7 (I believe srb put it together), but since V7 was going to go outside of Bell to the "general population" in the CS research community, it seemed like that was a good time to take back some it (by V8 they stopped trying and Research and Summit diverged). > Does anyone on-list know the providence of this document by the way? It was written at USG. I do not know by whom. That would be a good question to ask aps, as he and Ted were officemates at Summit. He might not. I have no idea if they had professional tech writers or if it was a new "product" from USG for the operating companies. BTW: the scan that archive.org has is missing at least the last 6 pages. > The scan edges indicate it came from a comb-bound volume, I'd be curious > if these were the only pages, Ted's copy was bound withg both holes the funky 2 pin standard AT&T binder, as well as industry standard 3 hole. > if that volume contained other UNIX stuff, no > and especially if this implies other comb-binding of manuals at the time. > GBC-style binding was used for things like the core UNIX manual set. In fact, Brian Redman (*a.k.a.* ber) took his 8.5 x 11 master for 4.1BSD, the same printer that USG was using, to make the first set of 6" x 9" GBC-bound BSD manuals. I've forgotten the details, but USENIX eventually took over get those printed (and offering them for sale to USENIX members). By the time of 4.3BSD, it had become a standard practice. > > Reason I ask is I seem to recall reading a post here or on a Usenet list > by Ted Dolotta I believe detailing that the Release 3.0 manuals got > approval to be printed on the same comb-bound stock used for internal phone > directories, and that it was the first time USG had "published" a manual so > formally. Hmmm - I'm not so sure of this. I thought PWB 1 and PWB 2 had 6" x 9" GBC-bound. Since Ted was part of PWB, it is likely that PWB 1.0, which Dolotta created, was the 6" x 9" GBC-bound "standard" for UNIX. I do know this: when 4.4 BSD was released, USENIX transferred the publishing task over to Tim O'Reilly. I remember having a conversation with him about the GBC binding. If he continued it, it would significantly increase the cost of each book, compared with the perfect-binding scheme he would eventually use for his 4.4BSD series. > Seeing the comb-binding holes in the scan casts some doubt on this. > I suspect someone xeroxgraphicly copied the original and put the result through a GBC punch From tuhs at tuhs.org Sat Jan 3 06:42:53 2026 From: tuhs at tuhs.org (David Barto via TUHS) Date: Fri, 2 Jan 2026 12:42:53 -0800 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> Message-ID: <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> > On Jan 2, 2026, at 12:33 PM, Clem Cole via TUHS wrote: > > BTW: the scan that archive.org has is missing at least the last 6 pages. Does anyone know/have any idea where a complete version of this document may be? I’ve had this one for a while, incomplete though it may be. A complete version would be "nice to have.” David From tuhs at tuhs.org Sat Jan 3 06:56:31 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 02 Jan 2026 20:56:31 +0000 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> Message-ID: On Friday, January 2nd, 2026 at 12:43, David Barto via TUHS wrote: > > On Jan 2, 2026, at 12:33 PM, Clem Cole via TUHS tuhs at tuhs.org wrote: > > > > BTW: the scan that archive.org http://archive.org/ has is missing at least the last 6 pages. > > > Does anyone know/have any idea where a complete version of this document may be? > > I’ve had this one for a while, incomplete though it may be. A complete version would be "nice to have.” > > David This same document is in the archive: https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf Unfortunately it appears to be the same scan missing the tail end. Looks like Lubomir Rintel did a troff restoration: https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description-troffsrc.tar.gz Given that this is based on the scan, it is also incomplete. - Matt G. From tuhs at tuhs.org Sat Jan 3 08:04:49 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Fri, 2 Jan 2026 16:04:49 -0600 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> Message-ID: <1b110c8e-426c-4e92-8a05-93e3f663bd6e@gmail.com> old thread - mel might have the physical copy? Warren Toomey > wrote: >/All, I've just received the following e-mail. I am not able to physically />/get these documents, but if you are interested in them, feel free to contact />/Mel yourself. />//>/Cheers, Warren />//>/----- Forwarded message from meljmel-unix at yahoo.com ----- />//>/Date: Wed, 23 May 2018 13:30:09 +1000 (AEST) />/From: meljmel-unix at yahoo.com />/To: Warren T > />/Subject: Old Unix manuals, TMs, etc />//>//>/Hi, />//>/I started working at Bell Labs in 1971 and although />/not in the computing science research department, I />/was in another department down the hall. As a result />/I have many old Unix manuals, TM's and other papers />/that I wish to dispose of. I found you when I did a />/search to see if there was anyone who might want them. />/Appended below is a list of what I have. If you are />/interested in any of it or know who else might be, please />/let me know. If I can't find anyone to take them I guess />/I'll just throw them out. />//>/Mel />/meljmel-unix at yahoo.com />//>/========== />/These are the old Unix Manuals I have: />//>/UNIX PROGRAMMER'S MANUAL />/Program Generic PG-1C300 Issue 2 />/Published by the UNIX Support Group />/January, 1976 />//>/UNIX PROGRAMMER'S MANUAL />/Program Generic PG-1C300 Issue 3 />/Published by the UNIX Support Group />/March, 1977/ On 1/2/26 14:56, segaloco via TUHS wrote: > On Friday, January 2nd, 2026 at 12:43, David Barto via TUHS wrote: > >>> On Jan 2, 2026, at 12:33 PM, Clem Cole via TUHStuhs at tuhs.org wrote: >>> >>> BTW: the scan that archive.orghttp://archive.org/ has is missing at least the last 6 pages. >> >> Does anyone know/have any idea where a complete version of this document may be? >> >> I’ve had this one for a while, incomplete though it may be. A complete version would be "nice to have.” >> >> David > This same document is in the archive: > > https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf > > Unfortunately it appears to be the same scan missing the tail end. > Looks like Lubomir Rintel did a troff restoration: > > https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description-troffsrc.tar.gz > > Given that this is based on the scan, it is also incomplete. > > - Matt G. From tuhs at tuhs.org Sat Jan 3 09:32:06 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Fri, 2 Jan 2026 15:32:06 -0800 Subject: [TUHS] Release Dates, Systems History - (was Did System V Really Prevent 5BSD?) In-Reply-To: References: Message-ID: <51fd32b7-60ef-460b-b22c-f80731b59aaf@mhorton.net> On 12/29/25 13:10, Clem Cole via TUHS wrote: > - Initial Internal Release: Some sources indicate an initial release in > 1980. This was likely a pre-commercial version known internally by names > such as UNIX/TS 3.0.1 or UNIX Release 3.0. > - Official Commercial Release: AT&T formally announced System III in > late 1981, and it was first made publicly (commercially) > available outside > of the Bell System in 1982. My UNIX Release 3.0 manual is dated June 1980. It's from Dolotta, olsson, and Petruccelli, Lab 364. The Acknowledgements page describes it (the manual) as descended from V6, UNIX/TS 1.1, and PWB/UNIX 2.0. My understanding is that this eventually turned into System III. > AT&T's UNIX System V had major releases starting with the initial System V 1983, My UNIX Release 5.0 manual is dated June 1982. It was internal to Bell Labs Division 452 (the computer centers). I understand this turned into System V. Thanks, /Mary Ann Horton/ (she/her/ma'am)       Award Winning Author maryannhorton.com From tuhs at tuhs.org Sat Jan 3 10:18:32 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 2 Jan 2026 17:18:32 -0700 Subject: [TUHS] Release Dates, Systems History - (was Did System V Really Prevent 5BSD?) In-Reply-To: <51fd32b7-60ef-460b-b22c-f80731b59aaf@mhorton.net> References: <51fd32b7-60ef-460b-b22c-f80731b59aaf@mhorton.net> Message-ID: On Fri, Jan 2, 2026 at 4:32 PM Mary Ann Horton via TUHS wrote: > On 12/29/25 13:10, Clem Cole via TUHS wrote: > > - Initial Internal Release: Some sources indicate an initial release in > > 1980. This was likely a pre-commercial version known internally > by names > > such as UNIX/TS 3.0.1 or UNIX Release 3.0. > > - Official Commercial Release: AT&T formally announced System III > in > > late 1981, and it was first made publicly (commercially) > > available outside > > of the Bell System in 1982. > My UNIX Release 3.0 manual is dated June 1980. It's from Dolotta, > olsson, and Petruccelli, Lab 364. The Acknowledgements page describes it > (the manual) as descended from V6, UNIX/TS 1.1, and PWB/UNIX 2.0. My > understanding is that this eventually turned into System III. > > AT&T's UNIX System V had major releases starting with the initial System > V 1983, > > My UNIX Release 5.0 manual is dated June 1982. It was internal to Bell > Labs Division 452 (the computer centers). I understand this turned into > System V. > 4.1BSD was July 1981 4.1aBSD was April 1982 4.1cBSD was Late 1982 This leaves us with Kirk's story lining up in two possible ways: 1. If the reason is System V, then the dates line up well to 4.1->5.0 plans changing to 4.1->4.2. 2. If the reason is Unix 5.0 plans that were hatched when 3.0 was released, then it does line up with the 4->5BSD plans vs 4BSD -> 4.1BSD actual. I'll see if I can get a peek at the dates of the printouts next time I'm at Kirk's house which would tell us for sure. He's quite sure the reason was AT&T. I see now that I didn't ask this detail... I'll follow up with him. Warner From tuhs at tuhs.org Sat Jan 3 11:49:59 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 2 Jan 2026 20:49:59 -0500 Subject: [TUHS] UINX Program Description: For V6 Unix. In-Reply-To: <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> References: <13941B9E-ACE0-4C53-893B-E203BC46A7D9@kdbarto.org> <0DA63EF7-4333-4C0C-AAC4-74D1DA50C526@kdbarto.org> Message-ID: On Fri, Jan 2, 2026 at 3:43 PM David Barto wrote: > > > On Jan 2, 2026, at 12:33 PM, Clem Cole via TUHS wrote: > > BTW: the scan that archive.org has is missing at least the last 6 pages. > > > Does anyone know/have any idea where a complete version of this document > may be? > Yes, sitting in a binder in front of me. > > I’ve had this one for a while, incomplete though it may be. A complete > version would be "nice to have.” > > David > > From tuhs at tuhs.org Sat Jan 3 15:56:01 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 03 Jan 2026 05:56:01 +0000 Subject: [TUHS] Release Dates, Systems History - (was Did System V Really Prevent 5BSD?) In-Reply-To: References: <51fd32b7-60ef-460b-b22c-f80731b59aaf@mhorton.net> Message-ID: On Friday, January 2nd, 2026 at 16:18, Warner Losh via TUHS wrote: > On Fri, Jan 2, 2026 at 4:32 PM Mary Ann Horton via TUHS tuhs at tuhs.org > > wrote: > > > On 12/29/25 13:10, Clem Cole via TUHS wrote: > > > > > - Initial Internal Release: Some sources indicate an initial release in > > > 1980. This was likely a pre-commercial version known internally > > > by names > > > such as UNIX/TS 3.0.1 or UNIX Release 3.0. > > > - Official Commercial Release: AT&T formally announced System III > > > in > > > late 1981, and it was first made publicly (commercially) > > > available outside > > > of the Bell System in 1982. > > > My UNIX Release 3.0 manual is dated June 1980. It's from Dolotta, > > > olsson, and Petruccelli, Lab 364. The Acknowledgements page describes it > > > (the manual) as descended from V6, UNIX/TS 1.1, and PWB/UNIX 2.0. My > > > understanding is that this eventually turned into System III. > > > AT&T's UNIX System V had major releases starting with the initial System > > > V 1983, > > > > My UNIX Release 5.0 manual is dated June 1982. It was internal to Bell > > Labs Division 452 (the computer centers). I understand this turned into > > System V. > > > 4.1BSD was July 1981 > 4.1aBSD was April 1982 > 4.1cBSD was Late 1982 > > This leaves us with Kirk's story lining up in two possible ways: > 1. If the reason is System V, then the dates line up well to 4.1->5.0 plans > > changing to 4.1->4.2. > > 2. If the reason is Unix 5.0 plans that were hatched when 3.0 was released, > then it does line up with the 4->5BSD plans vs 4BSD -> 4.1BSD actual. > > > I'll see if I can get a peek at the dates of the printouts next time I'm at > Kirk's > house which would tell us for sure. He's quite sure the reason was AT&T. > I see now that I didn't ask this detail... I'll follow up with him. > > Warner Bill Joy gives November 1980 as the distribution date of 4BSD, and then April 1981 as the date of the initial 4.1BSD revision[1]. This is the earliest date I can find given for anything named 4.1BSD. - Matt G. [1] - https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/usr/man/man0/changes.4-81 From tuhs at tuhs.org Sun Jan 4 13:09:18 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Sat, 3 Jan 2026 22:09:18 -0500 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: I don't remember how it was decided that the time had come for another edition. I volunteered to edit volume 1 of the manual. Andrew Hume took on volume 2, which ultimately split into 2A and 2B. We exercised some judgment about what should be in userland, wheedled contributions to the manual out of folks, and prodded fixes that would minimize the man-page BUGS sections. Maybe we rated the title of release provocateurs. As always in Unix, no one had ultimate authority. The most vivid example in v7 is that I didn't want uucp with its known security holes, but Mike Lesk could not be persuaded to work on closing them. It finally was included on the premise that it posed no new danger since it was already in widespread use. ---------- Forwarded message --------- From: Clem Cole Date: Sat, Jan 3, 2026 at 11:08 AM Subject: Re: V7 RE To: srb gmail Cc: Douglas McIlroy Thank you. Fair enough. I was sure you had been heavily involved. Doug, your memory? On Sat, Jan 3, 2026 at 9:53 AM srb gmail wrote: > > "As I understand it, Dennis did not want to be the "release > engineer" for V7 (I believe srb put it together), but since V7 was going to > go outside of Bell to the "general population" in the CS research > community, it seemed like that was a good time to take back some it (by V8 > they stopped trying and Research and Summit diverged)." > > Hi Clem, I did some of the release engineering for V7. Wrote scripts to make sure the release tree had > src, bin and man pages and some other cleanup and checks. Doug I think was the official RE but he would > probably remember better than me. > > Steve From tuhs at tuhs.org Sun Jan 4 13:21:42 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sat, 3 Jan 2026 22:21:42 -0500 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: Thank you. Funny your story about uucp. In the end, it was probably the most significant new tool out side of the Bell system that came from Seventh Edition. Clem Sent from a handheld expect more typos than usual On Sat, Jan 3, 2026 at 10:09 PM Douglas McIlroy via TUHS wrote: > I don't remember how it was decided that the time had come for another > edition. I volunteered to edit volume 1 of the manual. Andrew Hume > took on volume 2, which ultimately split into 2A and 2B. We exercised > some judgment about what should be in userland, wheedled contributions > to the manual out of folks, and prodded fixes that would minimize the > man-page BUGS sections. Maybe we rated the title of release > provocateurs. > > As always in Unix, no one had ultimate authority. The most vivid > example in v7 is that I didn't want uucp with its known security > holes, but Mike Lesk could not be persuaded to work on closing them. > It finally was included on the premise that it posed no new danger > since it was already in widespread use. > > ---------- Forwarded message --------- > From: Clem Cole > Date: Sat, Jan 3, 2026 at 11:08 AM > Subject: Re: V7 RE > To: srb gmail > Cc: Douglas McIlroy > > > Thank you. Fair enough. I was sure you had been heavily involved. > Doug, your memory? > > On Sat, Jan 3, 2026 at 9:53 AM srb gmail wrote: > > > > "As I understand it, Dennis did not want to be the "release > > engineer" for V7 (I believe srb put it together), but since V7 was going > to > > go outside of Bell to the "general population" in the CS research > > community, it seemed like that was a good time to take back some it (by > V8 > > they stopped trying and Research and Summit diverged)." > > > > Hi Clem, I did some of the release engineering for V7. Wrote scripts to > make sure the release tree had > > src, bin and man pages and some other cleanup and checks. Doug I think > was the official RE but he would > > probably remember better than me. > > > > Steve > From tuhs at tuhs.org Sun Jan 4 14:41:50 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sun, 4 Jan 2026 15:41:50 +1100 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > Also, while looking for the vi cards, I turned up two wonderful artifacts > that I'll try to get scanned and added to TUHS at some point. When you > purchased V7 from AT&T, you got one copy of the printed docs and a small > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > similar but different. Was the first edition also distributed to V6 licensees? -- UNIX Reference Card - First Edition L. L. Cherry September, 1975 A handy guide to UNIX commands and syntax. mentioned in: tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 v10/doc/bibliog.a unpm-docs -- UNIX Reference Card distributed by Computing Information Service BELL LABORATORIES Murray Hill, N. J. 07974 compiled by Lorinda Cherry Second Edition, March 1979 incomplete scan, some pages missing: http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf via http://www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm CHM has a copy, not currently scanned https://www.computerhistory.org/collections/catalog/102632799/ spiral bound https://www.flickr.com/photos/n1kdo/53136436051 comb bound https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 From tuhs at tuhs.org Sun Jan 4 18:28:41 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 04 Jan 2026 08:28:41 +0000 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: On Saturday, January 3rd, 2026 at 20:42, Jonathan Gray via TUHS wrote: > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > Also, while looking for the vi cards, I turned up two wonderful artifacts > > that I'll try to get scanned and added to TUHS at some point. When you > > purchased V7 from AT&T, you got one copy of the printed docs and a small > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > similar but different. > > > Was the first edition also distributed to V6 licensees? > > -- > > UNIX Reference Card - First Edition > L. L. Cherry > September, 1975 > A handy guide to UNIX commands and syntax. > > mentioned in: > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > v10/doc/bibliog.a unpm-docs > > -- > > UNIX Reference Card > distributed by > Computing Information Service > BELL LABORATORIES > Murray Hill, N. J. 07974 > compiled by Lorinda Cherry > Second Edition, March 1979 > > incomplete scan, some pages missing: > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > via http://www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > CHM has a copy, not currently scanned > https://www.computerhistory.org/collections/catalog/102632799/ > > spiral bound > https://www.flickr.com/photos/n1kdo/53136436051 > comb bound > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 Ah shoot, I actually have an unknown-generations-removed photocopy of this V6 flipbook, I should scan that. For the record, among the Release 4.0 documents I scanned for Arnold Robbins is that release's issue of this flipbook (I think they're genetically linked anyway): https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/UNIX_Reference_Guide.pdf - Matt G. From tuhs at tuhs.org Mon Jan 5 01:17:52 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Sun, 4 Jan 2026 07:17:52 -0800 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: <20260104151752.GA4609@mcvoy.com> To the extent that uucp enabled usenet, yeah, huge impact. He says with full knowledge that uucp always seemed to need baby sitting. Honey Danber was better but I seem to recall it needed baby sitting as well. I'm most definitely not complaining, uucp/usenet gave us a sense of community that was awesome. On Sat, Jan 03, 2026 at 10:21:42PM -0500, Clem Cole via TUHS wrote: > Thank you. Funny your story about uucp. In the end, it was probably the > most significant new tool out side of the Bell system that came from > Seventh Edition. > > Clem > > Sent from a handheld expect more typos than usual > > > On Sat, Jan 3, 2026 at 10:09???PM Douglas McIlroy via TUHS > wrote: > > > I don't remember how it was decided that the time had come for another > > edition. I volunteered to edit volume 1 of the manual. Andrew Hume > > took on volume 2, which ultimately split into 2A and 2B. We exercised > > some judgment about what should be in userland, wheedled contributions > > to the manual out of folks, and prodded fixes that would minimize the > > man-page BUGS sections. Maybe we rated the title of release > > provocateurs. > > > > As always in Unix, no one had ultimate authority. The most vivid > > example in v7 is that I didn't want uucp with its known security > > holes, but Mike Lesk could not be persuaded to work on closing them. > > It finally was included on the premise that it posed no new danger > > since it was already in widespread use. > > > > ---------- Forwarded message --------- > > From: Clem Cole > > Date: Sat, Jan 3, 2026 at 11:08???AM > > Subject: Re: V7 RE > > To: srb gmail > > Cc: Douglas McIlroy > > > > > > Thank you. Fair enough. I was sure you had been heavily involved. > > Doug, your memory? > > > > On Sat, Jan 3, 2026 at 9:53???AM srb gmail wrote: > > > > > > "As I understand it, Dennis did not want to be the "release > > > engineer" for V7 (I believe srb put it together), but since V7 was going > > to > > > go outside of Bell to the "general population" in the CS research > > > community, it seemed like that was a good time to take back some it (by > > V8 > > > they stopped trying and Research and Summit diverged)." > > > > > > Hi Clem, I did some of the release engineering for V7. Wrote scripts to > > make sure the release tree had > > > src, bin and man pages and some other cleanup and checks. Doug I think > > was the official RE but he would > > > probably remember better than me. > > > > > > Steve > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Mon Jan 5 03:17:24 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 4 Jan 2026 12:17:24 -0500 Subject: [TUHS] Fwd: V7 RE In-Reply-To: <20260104151752.GA4609@mcvoy.com> References: <20260104151752.GA4609@mcvoy.com> Message-ID: Yes, uucp, usenet, net news et al demonstrated MetCalf’s Law. But it came at a heavy user admin price too. I suspect much of that was due to traffic volume of news systems on top of the uucp routing scheme. Sent from a handheld expect more typos than usual On Sun, Jan 4, 2026 at 10:17 AM Larry McVoy wrote: > To the extent that uucp enabled usenet, yeah, huge impact. He says with > full knowledge that uucp always seemed to need baby sitting. Honey > Danber was better but I seem to recall it needed baby sitting as well. > > I'm most definitely not complaining, uucp/usenet gave us a sense of > community that was awesome. > > On Sat, Jan 03, 2026 at 10:21:42PM -0500, Clem Cole via TUHS wrote: > > Thank you. Funny your story about uucp. In the end, it was probably the > > most significant new tool out side of the Bell system that came from > > Seventh Edition. > > > > Clem > > > > Sent from a handheld expect more typos than usual > > > > > > On Sat, Jan 3, 2026 at 10:09???PM Douglas McIlroy via TUHS < > tuhs at tuhs.org> > > wrote: > > > > > I don't remember how it was decided that the time had come for another > > > edition. I volunteered to edit volume 1 of the manual. Andrew Hume > > > took on volume 2, which ultimately split into 2A and 2B. We exercised > > > some judgment about what should be in userland, wheedled contributions > > > to the manual out of folks, and prodded fixes that would minimize the > > > man-page BUGS sections. Maybe we rated the title of release > > > provocateurs. > > > > > > As always in Unix, no one had ultimate authority. The most vivid > > > example in v7 is that I didn't want uucp with its known security > > > holes, but Mike Lesk could not be persuaded to work on closing them. > > > It finally was included on the premise that it posed no new danger > > > since it was already in widespread use. > > > > > > ---------- Forwarded message --------- > > > From: Clem Cole > > > Date: Sat, Jan 3, 2026 at 11:08???AM > > > Subject: Re: V7 RE > > > To: srb gmail > > > Cc: Douglas McIlroy > > > > > > > > > Thank you. Fair enough. I was sure you had been heavily involved. > > > Doug, your memory? > > > > > > On Sat, Jan 3, 2026 at 9:53???AM srb gmail wrote: > > > > > > > > "As I understand it, Dennis did not want to be the "release > > > > engineer" for V7 (I believe srb put it together), but since V7 was > going > > > to > > > > go outside of Bell to the "general population" in the CS research > > > > community, it seemed like that was a good time to take back some it > (by > > > V8 > > > > they stopped trying and Research and Summit diverged)." > > > > > > > > Hi Clem, I did some of the release engineering for V7. Wrote > scripts to > > > make sure the release tree had > > > > src, bin and man pages and some other cleanup and checks. Doug I > think > > > was the official RE but he would > > > > probably remember better than me. > > > > > > > > Steve > > > > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > From tuhs at tuhs.org Mon Jan 5 04:37:33 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 04 Jan 2026 18:37:33 +0000 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: On Sunday, January 4th, 2026 at 00:29, segaloco via TUHS wrote: > On Saturday, January 3rd, 2026 at 20:42, Jonathan Gray via TUHS tuhs at tuhs.org wrote: > > > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > > > Also, while looking for the vi cards, I turned up two wonderful artifacts > > > that I'll try to get scanned and added to TUHS at some point. When you > > > purchased V7 from AT&T, you got one copy of the printed docs and a small > > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > > similar but different. > > > > Was the first edition also distributed to V6 licensees? > > > > -- > > > > UNIX Reference Card - First Edition > > L. L. Cherry > > September, 1975 > > A handy guide to UNIX commands and syntax. > > > > mentioned in: > > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > > v10/doc/bibliog.a unpm-docs > > > > -- > > > > UNIX Reference Card > > distributed by > > Computing Information Service > > BELL LABORATORIES > > Murray Hill, N. J. 07974 > > compiled by Lorinda Cherry > > Second Edition, March 1979 > > > > incomplete scan, some pages missing: > > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > > via http://www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > > > CHM has a copy, not currently scanned > > https://www.computerhistory.org/collections/catalog/102632799/ > > > > spiral bound > > https://www.flickr.com/photos/n1kdo/53136436051 > > comb bound > > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 > > > Ah shoot, I actually have an unknown-generations-removed photocopy of this V6 flipbook, I should scan that. > > For the record, among the Release 4.0 documents I scanned for Arnold Robbins is that release's issue of this flipbook (I think they're genetically linked anyway): https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/UNIX_Reference_Guide.pdf > > - Matt G. Found it, my copy appears to be the first issue (V6 era rather than V7), predating the scan above. Two standard punch holes are visible in the top edge of the printout, presumably the original was bound with a couple of brads in a flipbook. I'll plan on scanning this in the coming weeks. Unfortunately the cover and title page aren't in this copy, but I think everything else is there, the page numbers are sequential except one that coincides with what was probably a blank page in the original. More to come. - Matt G. From tuhs at tuhs.org Mon Jan 5 06:07:07 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Sun, 4 Jan 2026 12:07:07 -0800 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> I also have a copy of Cherry's booklet (spiral bound, 1979) in my collection. Comparing it with the incompete chilton scan, it's only missing pages 4 and 22. The other missing pages are blank. I gather this is the same one Clem has? If not, let me know and I'll scan it. Thanks, /Mary Ann Horton/ (she/her/ma'am)       Award Winning Author maryannhorton.com On 1/3/26 20:41, Jonathan Gray via TUHS wrote: > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: >> Also, while looking for the vi cards, I turned up two wonderful artifacts >> that I'll try to get scanned and added to TUHS at some point. When you >> purchased V7 from AT&T, you got one copy of the printed docs and a small >> "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry >> compiled. Also, when DEC released V7M-11, they printed a small flip-binding >> 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is >> similar but different. > Was the first edition also distributed to V6 licensees? > > -- > > UNIX Reference Card - First Edition > L. L. Cherry > September, 1975 > A handy guide to UNIX commands and syntax. > > mentioned in: > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > v10/doc/bibliog.a unpm-docs > > -- > > UNIX Reference Card > distributed by > Computing Information Service > BELL LABORATORIES > Murray Hill, N. J. 07974 > compiled by Lorinda Cherry > Second Edition, March 1979 > > incomplete scan, some pages missing: > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > viahttp://www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > CHM has a copy, not currently scanned > https://www.computerhistory.org/collections/catalog/102632799/ > > spiral bound > https://www.flickr.com/photos/n1kdo/53136436051 > comb bound > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 From tuhs at tuhs.org Mon Jan 5 20:17:22 2026 From: tuhs at tuhs.org (Liam Proven via TUHS) Date: Mon, 5 Jan 2026 10:17:22 +0000 Subject: [TUHS] unix v4 tape found In-Reply-To: <37A35DF4-FC08-4702-AE71-3E707E57707F@canb.auug.org.au> References: <37A35DF4-FC08-4702-AE71-3E707E57707F@canb.auug.org.au> Message-ID: On Wed, 24 Dec 2025 at 01:23, steve jenkin via TUHS wrote: > > Liam Proven has written a nice piece in ’The Register’, includes history, why finding this piece is important & more. > > Links to videos and many CHM and other sources, including Oral Histories. > > LP wonders “Is this a Christmas Miracle?” > It’s certainly the original CSRC spirit of “Cooperation and Collegiality” alive & well. > > Link & extract at end. Oh, hey, that's me! Thank you Steve, and for the heads-up as well. I have a fairly significant backlog on some of my mailing lists and this is one of them. :-( Both the original article and the follow-up on the recovery seem to have gone down very well judging by the number of comments -- one of the few metrics that I can see as a mere reporter. (Dates embedded in the URLs.) https://www.theregister.com/2025/11/07/unix_fourth_edition_tape_rediscovered/ https://www.theregister.com/2025/12/23/unix_v4_tape_successfully_recovered/ -- Liam Proven ~ Profile: https://about.me/liamproven ~ LinkedIn/X/FB: lproven Email: lproven at cix.co.uk ~ Google: lproven at gmail.com IoM: (+44) 7624 227612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 From tuhs at tuhs.org Tue Jan 6 00:12:07 2026 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Mon, 5 Jan 2026 09:12:07 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) Message-ID: From the "crytography" mailing list: https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/ From tuhs at tuhs.org Tue Jan 6 01:19:52 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Mon, 5 Jan 2026 10:19:52 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) Message-ID: So somebody spotted a buffer overflow in v4.5, ironically in su. Overflowable buffers were common in those days. It was all too easy when programming to shrug one's shoulders and opine that nobody would ever want to input a 200-character line, say, so why bother writing the extra code to catch it? We did gradually learn that automatically generated input lines--particularly lines of code--could be much longer than any person would write, so buffer overflows that actually happened gradually got fixed. Dennis once fed a couple-of-thousand-byte line on standard input to everything in /bin. Crashes abounded, but so what? Wasn't a crash just an ungraceful way for a program to say "I can't handle this"? Not until the Morris worm (1988) did folks wake up to the real danger of overflows. Sometime after Dennis's casual experiment, a paper that announced the same results got the reaction, "So what else is new?" from the Unix room. It would be interesting to find the paper and compare its "shocked, shocked" presentation to that of the rediscovery posted on the cryptography mailing list. Doug From tuhs at tuhs.org Tue Jan 6 01:40:48 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Mon, 5 Jan 2026 10:40:48 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 10:20 AM Douglas McIlroy via TUHS wrote: > > Overflowable buffers were common in those days. It was all too easy > when programming to shrug one's shoulders and opine that nobody would > ever want to input a 200-character line, say, so why bother writing > the extra code to catch it? We did gradually learn that automatically > generated input lines--particularly lines of code--could be much > longer than any person would write, so buffer overflows that actually > happened gradually got fixed. > > There was another consideration. Machines in those days were slow and had tiny memory capacity. Was it really worth wasting the extra memory space and CPU time for buffer overflow checking in cases where it was extremely unlikely to occur? -Paul W. From tuhs at tuhs.org Tue Jan 6 01:51:11 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 5 Jan 2026 08:51:11 -0700 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 8:41 AM Paul Winalski via TUHS wrote: > On Mon, Jan 5, 2026 at 10:20 AM Douglas McIlroy via TUHS > wrote: > > > > > Overflowable buffers were common in those days. It was all too easy > > when programming to shrug one's shoulders and opine that nobody would > > ever want to input a 200-character line, say, so why bother writing > > the extra code to catch it? We did gradually learn that automatically > > generated input lines--particularly lines of code--could be much > > longer than any person would write, so buffer overflows that actually > > happened gradually got fixed. > > > There was another consideration. Machines in those days were slow and had > tiny memory capacity. Was it really worth wasting the extra memory space > and CPU time for buffer overflow checking in cases where it was extremely > unlikely to occur? > Yes. It's hard to believe today, but in the pre-morris-worm era, buffer overflows only mattered if they crashed the program and even then they were often ignored due to execution time and/or code bloat considerations. One of the trade offs we were taught in my OS class was when to check: Crashing the kernel is bad, so check there, but make the check as cheap as you can. In userland, just let the program crash: that's zero cost feedback. Almost[*] everybody was going around, like in the princess bride, saying problems from this attitude were "Inconceivable" but the morris worm was the "You keep on using that word, I don't think it means what you think it means" moment that changed everything. Warner [*] We all know the classic papers that were ignored pre-worm... From tuhs at tuhs.org Tue Jan 6 02:15:00 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 5 Jan 2026 11:15:00 -0500 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) Message-ID: Does anyone have a copy of the paper mentioned in the subject? From tuhs at tuhs.org Tue Jan 6 02:21:56 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Mon, 5 Jan 2026 11:21:56 -0500 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: As I understand what Michael Lesk has said about UUCP, it was created to bridge a three week gap before a full-fledged networking product was due to be released by the product folks. Somehow that sounds incredibly familiar. ===== mindthegapdialogs.com north-fork.info On Sat, Jan 3, 2026 at 10:09 PM Douglas McIlroy via TUHS wrote: > I don't remember how it was decided that the time had come for another > edition. I volunteered to edit volume 1 of the manual. Andrew Hume > took on volume 2, which ultimately split into 2A and 2B. We exercised > some judgment about what should be in userland, wheedled contributions > to the manual out of folks, and prodded fixes that would minimize the > man-page BUGS sections. Maybe we rated the title of release > provocateurs. > > As always in Unix, no one had ultimate authority. The most vivid > example in v7 is that I didn't want uucp with its known security > holes, but Mike Lesk could not be persuaded to work on closing them. > It finally was included on the premise that it posed no new danger > since it was already in widespread use. > > ---------- Forwarded message --------- > From: Clem Cole > Date: Sat, Jan 3, 2026 at 11:08 AM > Subject: Re: V7 RE > To: srb gmail > Cc: Douglas McIlroy > > > Thank you. Fair enough. I was sure you had been heavily involved. > Doug, your memory? > > On Sat, Jan 3, 2026 at 9:53 AM srb gmail wrote: > > > > "As I understand it, Dennis did not want to be the "release > > engineer" for V7 (I believe srb put it together), but since V7 was going > to > > go outside of Bell to the "general population" in the CS research > > community, it seemed like that was a good time to take back some it (by > V8 > > they stopped trying and Research and Summit diverged)." > > > > Hi Clem, I did some of the release engineering for V7. Wrote scripts to > make sure the release tree had > > src, bin and man pages and some other cleanup and checks. Doug I think > was the official RE but he would > > probably remember better than me. > > > > Steve > From tuhs at tuhs.org Tue Jan 6 02:22:19 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 5 Jan 2026 11:22:19 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 10:51 AM Warner Losh via TUHS wrote: > On Mon, Jan 5, 2026 at 8:41 AM Paul Winalski via TUHS wrote: > > On Mon, Jan 5, 2026 at 10:20 AM Douglas McIlroy via TUHS wrote: > > > Overflowable buffers were common in those days. It was all too easy > > > when programming to shrug one's shoulders and opine that nobody would > > > ever want to input a 200-character line, say, so why bother writing > > > the extra code to catch it? We did gradually learn that automatically > > > generated input lines--particularly lines of code--could be much > > > longer than any person would write, so buffer overflows that actually > > > happened gradually got fixed. > > > > > There was another consideration. Machines in those days were slow and had > > tiny memory capacity. Was it really worth wasting the extra memory space > > and CPU time for buffer overflow checking in cases where it was extremely > > unlikely to occur? > > Yes. It's hard to believe today, but in the pre-morris-worm era, buffer > overflows only mattered if they crashed the program and even then > they were often ignored due to execution time and/or code bloat > considerations. One of the trade offs we were taught in my OS class > was when to check: Crashing the kernel is bad, so check there, > but make the check as cheap as you can. Indeed. My invariant has always been, "user programs should not be able to (directly) crash the kernel." I say, "directly" because there's an argument that some action taken by a user program might tickle a different problem (say, a faulty hardware device) that causes a crash and there may be little one can do about it, but it should never be the case that just giving a bad pointer or number to the kernel should result in a panic. > In userland, just let the program crash: that's zero cost feedback. > Almost[*] everybody was going around, like in the princess bride, > saying problems from this attitude were "Inconceivable" but the > morris worm was the "You keep on using that word, I don't think it > means what you think it means" moment that changed everything. Funny, I just watched that movie with my kids over the weekend.... But I'm not sure that was actually the turning point. I think it was the, "smashing the stack for fun and profit" paper that really got things going with respect to people being serious about buffer overruns and the like, at least locally. I rather got the impression that the Morris worm was seen as an interesting example of a category of problem, but mostly treated as a one-off. > [*] We all know the classic papers that were ignored pre-worm... I'm actually afraid that I do not, but it sounds like an interesting list. Any pointers to the top few? - Dan C. From tuhs at tuhs.org Tue Jan 6 02:23:19 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 5 Jan 2026 09:23:19 -0700 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: Do you know which product and what happened to it? Warner On Mon, Jan 5, 2026 at 9:22 AM Marc Donner via TUHS wrote: > As I understand what Michael Lesk has said about UUCP, it was created to > bridge a three week gap before a full-fledged networking product was due to > be released by the product folks. Somehow that sounds incredibly familiar. > ===== > mindthegapdialogs.com > north-fork.info > > > On Sat, Jan 3, 2026 at 10:09 PM Douglas McIlroy via TUHS > wrote: > > > I don't remember how it was decided that the time had come for another > > edition. I volunteered to edit volume 1 of the manual. Andrew Hume > > took on volume 2, which ultimately split into 2A and 2B. We exercised > > some judgment about what should be in userland, wheedled contributions > > to the manual out of folks, and prodded fixes that would minimize the > > man-page BUGS sections. Maybe we rated the title of release > > provocateurs. > > > > As always in Unix, no one had ultimate authority. The most vivid > > example in v7 is that I didn't want uucp with its known security > > holes, but Mike Lesk could not be persuaded to work on closing them. > > It finally was included on the premise that it posed no new danger > > since it was already in widespread use. > > > > ---------- Forwarded message --------- > > From: Clem Cole > > Date: Sat, Jan 3, 2026 at 11:08 AM > > Subject: Re: V7 RE > > To: srb gmail > > Cc: Douglas McIlroy > > > > > > Thank you. Fair enough. I was sure you had been heavily involved. > > Doug, your memory? > > > > On Sat, Jan 3, 2026 at 9:53 AM srb gmail wrote: > > > > > > "As I understand it, Dennis did not want to be the "release > > > engineer" for V7 (I believe srb put it together), but since V7 was > going > > to > > > go outside of Bell to the "general population" in the CS research > > > community, it seemed like that was a good time to take back some it (by > > V8 > > > they stopped trying and Research and Summit diverged)." > > > > > > Hi Clem, I did some of the release engineering for V7. Wrote scripts > to > > make sure the release tree had > > > src, bin and man pages and some other cleanup and checks. Doug I think > > was the official RE but he would > > > probably remember better than me. > > > > > > Steve > > > From tuhs at tuhs.org Tue Jan 6 02:24:40 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Mon, 5 Jan 2026 11:24:40 -0500 Subject: [TUHS] Fwd: V7 RE In-Reply-To: References: Message-ID: I don't remember, but as I recall it never was actually released. Next time I see him I'll try to remember to ask. ===== mindthegapdialogs.com north-fork.info On Mon, Jan 5, 2026 at 11:23 AM Warner Losh wrote: > Do you know which product and what happened to it? > > Warner > > On Mon, Jan 5, 2026 at 9:22 AM Marc Donner via TUHS wrote: > >> As I understand what Michael Lesk has said about UUCP, it was created to >> bridge a three week gap before a full-fledged networking product was due >> to >> be released by the product folks. Somehow that sounds incredibly >> familiar. >> ===== >> mindthegapdialogs.com >> north-fork.info >> >> >> On Sat, Jan 3, 2026 at 10:09 PM Douglas McIlroy via TUHS >> wrote: >> >> > I don't remember how it was decided that the time had come for another >> > edition. I volunteered to edit volume 1 of the manual. Andrew Hume >> > took on volume 2, which ultimately split into 2A and 2B. We exercised >> > some judgment about what should be in userland, wheedled contributions >> > to the manual out of folks, and prodded fixes that would minimize the >> > man-page BUGS sections. Maybe we rated the title of release >> > provocateurs. >> > >> > As always in Unix, no one had ultimate authority. The most vivid >> > example in v7 is that I didn't want uucp with its known security >> > holes, but Mike Lesk could not be persuaded to work on closing them. >> > It finally was included on the premise that it posed no new danger >> > since it was already in widespread use. >> > >> > ---------- Forwarded message --------- >> > From: Clem Cole >> > Date: Sat, Jan 3, 2026 at 11:08 AM >> > Subject: Re: V7 RE >> > To: srb gmail >> > Cc: Douglas McIlroy >> > >> > >> > Thank you. Fair enough. I was sure you had been heavily involved. >> > Doug, your memory? >> > >> > On Sat, Jan 3, 2026 at 9:53 AM srb gmail wrote: >> > > >> > > "As I understand it, Dennis did not want to be the "release >> > > engineer" for V7 (I believe srb put it together), but since V7 was >> going >> > to >> > > go outside of Bell to the "general population" in the CS research >> > > community, it seemed like that was a good time to take back some it >> (by >> > V8 >> > > they stopped trying and Research and Summit diverged)." >> > > >> > > Hi Clem, I did some of the release engineering for V7. Wrote scripts >> to >> > make sure the release tree had >> > > src, bin and man pages and some other cleanup and checks. Doug I >> think >> > was the official RE but he would >> > > probably remember better than me. >> > > >> > > Steve >> > >> > From tuhs at tuhs.org Tue Jan 6 03:08:14 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Mon, 5 Jan 2026 12:08:14 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 10:51 AM Warner Losh wrote: > Yes. It's hard to believe today, but in the pre-morris-worm era, buffer > overflows only > mattered if they crashed the program and even then they were often ignored > due to execution time and/or code bloat considerations. > The problem with that philosophy is that a buffer overflow doesn't necessarily lead to a program crash. A program crash is the lucky outcome. If you're unlucky you will silently get the wrong answer, or other misbehavior. -Paul W. From tuhs at tuhs.org Tue Jan 6 03:12:46 2026 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Mon, 5 Jan 2026 12:12:46 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: We know a lot more now than we knew 50 years ago. That is a good thing. On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS wrote: > > On Mon, Jan 5, 2026 at 10:51 AM Warner Losh wrote: > > > Yes. It's hard to believe today, but in the pre-morris-worm era, buffer > > overflows only > > mattered if they crashed the program and even then they were often ignored > > due to execution time and/or code bloat considerations. > > > > The problem with that philosophy is that a buffer overflow doesn't > necessarily lead to a program crash. A program crash is the lucky > outcome. If you're unlucky you will silently get the wrong answer, or > other misbehavior. > > -Paul W. From tuhs at tuhs.org Tue Jan 6 03:27:30 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 5 Jan 2026 12:27:30 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS wrote: > The problem with that philosophy is that a buffer overflow doesn't > necessarily lead to a program crash. A program crash is the lucky > outcome. If you're unlucky you will silently get the wrong answer, or > other misbehavior. > Right - which is why it took something catastrophic like the Morris Worm and shortly thereafter, the infamous smash the stack paper: ( https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for people to wake up to the fact that it really was an issue for many programs. I recall that some of the language folks (particularly those heavily involved in the Pascal *vs.* C war) like to say things like: *"See, the compiler should have general bounds-checking code." *I can't say I agreed on the general topic (there were too many things Pascal got wrong), but note that today both Go and Rust provide automatic bounds checking for all array and slice accesses at runtime. From tuhs at tuhs.org Tue Jan 6 03:44:06 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 05 Jan 2026 10:44:06 -0700 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: <202601051744.605Hi6ga025548@freefriends.org> Clem Cole via TUHS wrote: > I recall that some of the language folks (particularly those heavily > involved in the Pascal *vs.* C war) like to say things like: *"See, the > compiler should have general bounds-checking code." *I can't say I agreed > on the general topic (there were too many things Pascal got wrong), but > note that today both Go and Rust provide automatic bounds checking for all > array and slice accesses at runtime. You can thank Moore's Law for that. We can afford the "penalty" on today's hardware. On yesterday's it was a *much* more painful decision. Arnold From tuhs at tuhs.org Tue Jan 6 03:46:50 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 5 Jan 2026 09:46:50 -0800 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Jan 5, 2026, at 9:27 AM, Clem Cole via TUHS wrote: > > On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS > wrote: > >> The problem with that philosophy is that a buffer overflow doesn't >> necessarily lead to a program crash. A program crash is the lucky >> outcome. If you're unlucky you will silently get the wrong answer, or >> other misbehavior. >> > Right - which is why it took something catastrophic like the Morris Worm > and shortly thereafter, the infamous smash the stack paper: ( > https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for > people to wake up to the fact that it really was an issue for many > programs. > > I recall that some of the language folks (particularly those heavily > involved in the Pascal *vs.* C war) like to say things like: *"See, the > compiler should have general bounds-checking code." *I can't say I agreed > on the general topic (there were too many things Pascal got wrong), but > note that today both Go and Rust provide automatic bounds checking for all > array and slice accesses at runtime. Actually Pascal got a lot of things right. Coming from being intimately familiar with Pascal and its orig. compiler, I disliked these things in C: 1. poor array support, no multi-dim arrays 2. C's union type vs Pascal's variant records 3. no subrange type 4. C's poor type system 5. C's enum type which are essentiall integers vs Pascal's strict enumeration type 6. No nested functions. [Of course, there were many things to like in C as well.] Granted, it was not as clean and orthogonal as Algol68 (whose popularity suffered from surface issues such as use of vW grammar od choice of keywords etc.). Also note that pretty much all non-C compilers pre-1988 generate code to do bounds check -- at least as an option but more often the option was to turn *off* bounds check! Now that we are aware of the danger of no bounds check, we seem to have gone to other extreme of using complicated languages like Rust.... From tuhs at tuhs.org Tue Jan 6 03:46:36 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 5 Jan 2026 12:46:36 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 12:28 PM Clem Cole via TUHS wrote: > On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS wrote: > > The problem with that philosophy is that a buffer overflow doesn't > > necessarily lead to a program crash. A program crash is the lucky > > outcome. If you're unlucky you will silently get the wrong answer, or > > other misbehavior. > > Right - which is why it took something catastrophic like the Morris Worm > and shortly thereafter, the infamous smash the stack paper: ( > https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for > people to wake up to the fact that it really was an issue for many > programs. > > I recall that some of the language folks (particularly those heavily > involved in the Pascal *vs.* C war) like to say things like: *"See, the > compiler should have general bounds-checking code." *I can't say I agreed > on the general topic (there were too many things Pascal got wrong), but > note that today both Go and Rust provide automatic bounds checking for all > array and slice accesses at runtime. Sadly, Rust turns it off for optimized ("Release") builds. Personally, I think that's a mistake; it ought to be an _explicit_ opt-out via a dedicated compiler option. I used to work with a former Microsofty who had worked on Midori, and who told me that M# (the variant of C# they used) did bounds checking for _all_ array accesses). At one point they tried to measure the cost of doing that, and realized it was down in the noise floor. - Dan C. From tuhs at tuhs.org Tue Jan 6 04:13:58 2026 From: tuhs at tuhs.org (Luther Johnson via TUHS) Date: Mon, 5 Jan 2026 11:13:58 -0700 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: <97fe5ae9-5080-126a-60c9-c1cfceaa58f9@makerlisp.com> I think in the beginning it just wasn't considered, that we had to protect against programs intentionally doing harm. Who would do that ? But now we know. On 01/05/2026 10:46 AM, Bakul Shah via TUHS wrote: > On Jan 5, 2026, at 9:27 AM, Clem Cole via TUHS wrote: >> On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS >> wrote: >> >>> The problem with that philosophy is that a buffer overflow doesn't >>> necessarily lead to a program crash. A program crash is the lucky >>> outcome. If you're unlucky you will silently get the wrong answer, or >>> other misbehavior. >>> >> Right - which is why it took something catastrophic like the Morris Worm >> and shortly thereafter, the infamous smash the stack paper: ( >> https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for >> people to wake up to the fact that it really was an issue for many >> programs. >> >> I recall that some of the language folks (particularly those heavily >> involved in the Pascal *vs.* C war) like to say things like: *"See, the >> compiler should have general bounds-checking code." *I can't say I agreed >> on the general topic (there were too many things Pascal got wrong), but >> note that today both Go and Rust provide automatic bounds checking for all >> array and slice accesses at runtime. > Actually Pascal got a lot of things right. Coming from being intimately > familiar with Pascal and its orig. compiler, I disliked these things in C: > 1. poor array support, no multi-dim arrays > 2. C's union type vs Pascal's variant records > 3. no subrange type > 4. C's poor type system > 5. C's enum type which are essentiall integers vs Pascal's strict enumeration type > 6. No nested functions. > > [Of course, there were many things to like in C as well.] > > Granted, it was not as clean and orthogonal as Algol68 (whose popularity > suffered from surface issues such as use of vW grammar od choice of keywords > etc.). > > Also note that pretty much all non-C compilers pre-1988 generate code to > do bounds check -- at least as an option but more often the option was to > turn *off* bounds check! > > Now that we are aware of the danger of no bounds check, we seem to have gone > to other extreme of using complicated languages like Rust.... From tuhs at tuhs.org Tue Jan 6 04:16:44 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 5 Jan 2026 13:16:44 -0500 Subject: [TUHS] C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; ) Message-ID: Moving to COFF, bcc TUHS On Mon, Jan 5, 2026 at 12:47 PM Bakul Shah wrote: > Actually Pascal got a lot of things right. Coming from being intimately > familiar with Pascal and its orig. compiler, I disliked these things in C: > 1. poor array support, no multi-dim arrays > 2. C's union type vs Pascal's variant records > 3. no subrange type > 4. C's poor type system > 5. C's enum type which are essentiall integers vs Pascal's strict > enumeration type > 6. No nested functions. > > [Of course, there were many things to like in C as well.] > > Granted, it was not as clean and orthogonal as Algol68 (whose popularity > suffered from surface issues such as use of vW grammar od choice of > keywords > etc.). > > Also note that pretty much all non-C compilers pre-1988 generate code to > do bounds check -- at least as an option but more often the option was to > turn *off* bounds check! > > Now that we are aware of the danger of no bounds check, we seem to have > gone > to other extreme of using complicated languages like Rust.... I, too, don't "hate" Pascal and don't argue with the strengths it demonstrated. But I have one primary issue: *"Which Pascal do you mean?" *When I worked at Tektronix, Ward Cunningham and I counted 14 different "Tek Pascals" in use at the time. The paper "*Why Pascal is not my Favorite Programming Language*" [ https://web.archive.org/web/20060821183401/http://cm.bell-labs.com/cm/cs/cstr/100.ps.gz ] offers up the fundamental issues. I suggest looking at Ward's Wiki [ https://wiki.c2.com/?WhyPascalIsNotMyFavoriteProgrammingLanguage ] as there are some interesting comments. I think this observation is also important: > "Interestingly, many of Kernighan's objections to Pascal are things that > Knuth also found it necessary to address in his LiterateProgramming > tool "Web", which he used in > the development of TexTheProgram and > Metafont. It is fair to say that the Web system is only half about > LiterateProgramming ; the other > half is just workarounds for the shortcomings of the Pascal dialects of its > day. Most notably, Web provides a mechanism to allow the use of > variable-length strings in things like error messages." From tuhs at tuhs.org Tue Jan 6 04:40:59 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Mon, 5 Jan 2026 13:40:59 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <97fe5ae9-5080-126a-60c9-c1cfceaa58f9@makerlisp.com> References: <97fe5ae9-5080-126a-60c9-c1cfceaa58f9@makerlisp.com> Message-ID: On Mon, Jan 5, 2026 at 1:14 PM Luther Johnson via TUHS wrote: [regarding buffer overflow checking] > I think in the beginning it just wasn't considered, that we had to > protect against programs intentionally doing harm. Who would do that ? > But now we know. > > With the good ole card-fed, raised floor mainframes, both the programs being run and their inputs were generally under strict, centralized control. Malicious code did still happen even then. Consider this story: The audit department at one of Hartford's major insurance companies received a phone call. It was from the head of the local BMW dealership. He told them, "One of your IT workers just paid cash for a top-of-the-line BMW. We thought you'd like to know that." It turns out that the IT worker was the programmer responsible for maintaining the program that prints the paychecks. The weekly pay calculation often yielded amounts in fractions of pennies. These were either rounded up or down to the nearest cent. The fractional pennies were tracked in an account called the breakage account. This programmer had created a fake employee in the company's computer records and had a check printed for that "person" containing the amount of money in the breakage account. He had been doing this for some time and had embezzled enough money to pay cash for a top-end Beemer. Malicious programming has always been with us. -Paul W. From tuhs at tuhs.org Tue Jan 6 05:05:58 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Mon, 05 Jan 2026 20:05:58 +0100 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> Dan Cross via TUHS wrote in : |On Mon, Jan 5, 2026 at 12:28 PM Clem Cole via TUHS wrote: |> On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS \ |> wrote: |>> The problem with that philosophy is that a buffer overflow doesn't |>> necessarily lead to a program crash. A program crash is the lucky |>> outcome. If you're unlucky you will silently get the wrong answer, or |>> other misbehavior. |> |> Right - which is why it took something catastrophic like the Morris Worm |> and shortly thereafter, the infamous smash the stack paper: ( |> https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for |> people to wake up to the fact that it really was an issue for many |> programs. |> |> I recall that some of the language folks (particularly those heavily |> involved in the Pascal *vs.* C war) like to say things like: *"See, the |> compiler should have general bounds-checking code." *I can't say \ |> I agreed |> on the general topic (there were too many things Pascal got wrong), but |> note that today both Go and Rust provide automatic bounds checking \ |> for all |> array and slice accesses at runtime. | |Sadly, Rust turns it off for optimized ("Release") builds. Personally, |I think that's a mistake; it ought to be an _explicit_ opt-out via a |dedicated compiler option. Sadly is -- to me -- that this "memory safe" storm blows away any factualities. Furthermore, it seems anyone is willing to join into this choir, and as always i do not know why. Maybe an outcome of some "boring company" (and hoping the term is not trademarketed beyond usability). |I used to work with a former Microsofty who had worked on Midori, and |who told me that M# (the variant of C# they used) did bounds checking |for _all_ array accesses). At one point they tried to measure the cost |of doing that, and realized it was down in the noise floor. ..and fact is that any language i know supports bound-checked array accesses. You only have to code it. And have the discipline to use that interface, and that interface alone. This argument extends to more things. In early September 2024 there was a very long thread on some FreeBSD list where a long time contributor and kernel hacker jumped into the at that time "hot" (there was that Linux filesystem discussion thing where a Rust promoter stepped down not back after claiming that ~"blocking Rust" is "non-technical nonsense" (Google says for "linux rust non-techincal nonsense"). And he said |> In fact, of all the C bug fixes that I've been involved with (as |> either author or reviewer) since May, about three quarters could've |> been avoided just by using a better language. |... |> To summarize, here's the list of this week's security advisories, and |> also some other recent C bug fixes of my own involvement That really interested me, and i looked over them [1], likely not longer than a minute code-looking for each one (claiming t"he ones from OpenSSL and ctld are more complex" instead of looking more deeply), and i ended up saying Examples. I find the absolute opposite after checking four. Later in the thread one developer of a patch i did not look further into because of complexity stated his was ~"not a C error" either. So that is that. And then, how could any language help when, as i say in [1], "a byte buffer of reality matches a structure of a language abstraction". More than C? And things often seen in C, beyond that struct{x;y;char flex[];}, where a larger buffer is allocated to store some structure at the bottom and a buffer thereafter, in one hot memory chunk. You can create an interface that accesses memory within "flex" safely, even then. And then you can use a string object that knows its length. And all that -- you all know that, better than i do. In the non-mellow sphere of programmers lots of sledgehammerheads bang into this "memory safe" notch, as if they were the "king of the bongo .. bong!". Whereas i think it is beneficial to create a wider context so that at least in certain forums different realities can be heard. Not that it all ends up with AI rewriting any C or C++ code in Rust, without any little human programmer getting paid for anything of that rewrite, which does not fix just one logic error. [1] https://marc.info/?l=freebsd-hackers&m=172557660704363&w=2 Array bound checking, i mean, come on. Cheech and Chong are beaners without that. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Tue Jan 6 06:20:34 2026 From: tuhs at tuhs.org (Lyndon Nerenberg (VE7TFX/VE6BBM) via TUHS) Date: Mon, 05 Jan 2026 12:20:34 -0800 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: Rich Salz via TUHS writes: > From the "crytography" mailing list: > https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/ I can't wait for the flood of V4-related CVEs :-P --lyndon From tuhs at tuhs.org Tue Jan 6 06:39:22 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 5 Jan 2026 15:39:22 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> Message-ID: [Note: TUHS to Bcc: and Cc: to COFF. This has nothing to do with Unix] On Mon, Jan 5, 2026 at 2:16 PM Steffen Nurpmeso via TUHS wrote: > [snip] > ..and fact is that any language i know supports bound-checked > array accesses. You only have to code it. And have the > discipline to use that interface, and that interface alone. > This argument extends to more things. Note: you took a note about what Rust does with bounds checking, and turned it into a rant about how you don't see value in memory safety. My experience is that people tend to react to languages things like Rust in one of three ways: 1) they are unabashed fan boys who suggest that anyone not programming in Rust is an idiot, 2) they acknowledge the strengths and potential benefits and can appreciate the positives of programming at a higher level of abstraction, while still pointing out flaws and being cautious about potential pitfalls (tooling, complexity, training, whatever; you name it), or 3) they assert that there's nothing useful here and anyone who's programming in Rust is an idiot desperately looking for tools to cover up their incompetence, and that the real solution is to just be a Better Programmer. Of course, Rust is just an example here; these broad categories of reactions are true of any number of technologies. Of the three, I've found that those falling into the first camp basically never write software but spend an awful lot of time writing blogs or commenting on hacker news. Those in the third category are similar, though they've likely _stopped_ writing lots of code. Those in the second category, who can appreciate nuance and weigh tradeoffs objectively, tend to be the best engineers. My own take here is your argument defeats itself in the above paragraph: 60 years of professional programming history have shown that those "only have to code it" and "having the discipline" things don't hold up at scale. Sure, we can all belly up to the bar and complain about how the kids these days just don't have the skill, intelligence, or intestinal fortitude to write competent C code, but professionals understand that tools evolve and defense-in-depth and automation are good when it comes to writing reliable software. If you think it's just a matter of discipline, well...good luck with that. History and available evidence disagree. > In early September 2024 there was a very long thread on some > FreeBSD list where a long time contributor and kernel hacker > jumped into the at that time "hot" (there was that Linux > filesystem discussion thing where a Rust promoter stepped down > not back after claiming that ~"blocking Rust" is "non-technical > nonsense" (Google says for "linux rust non-techincal nonsense"). > And he said > > |> In fact, of all the C bug fixes that I've been involved with (as > |> either author or reviewer) since May, about three quarters could've > |> been avoided just by using a better language. > |... > |> To summarize, here's the list of this week's security advisories, and > |> also some other recent C bug fixes of my own involvement > > That really interested me, and i looked over them [1], likely not > longer than a minute code-looking for each one (claiming t"he ones > from OpenSSL and ctld are more complex" instead of looking more > deeply), and i ended up saying > > Examples. I find the absolute opposite after checking four. I don't see how this can be claimed to be the "opposite." It may be that you aren't convinced that Rust has any advantages over C for the examples given that you looked at, but that is very different than claiming that Rust makes the code _worse_ and unsafe (which is what the opposite claim implies). > Later in the thread one developer of a patch i did not look > further into because of complexity stated his was ~"not a C error" > either. So that is that. > > And then, how could any language help when, as i say in [1], > "a byte buffer of reality matches a structure of a language > abstraction". More than C? > And things often seen in C, beyond that struct{x;y;char flex[];}, > where a larger buffer is allocated to store some structure at > the bottom and a buffer thereafter, in one hot memory chunk. > You can create an interface that accesses memory within "flex" > safely, even then. > And then you can use a string object that knows its length. > And all that -- you all know that, better than i do. > > In the non-mellow sphere of programmers lots of sledgehammerheads > bang into this "memory safe" notch, as if they were the "king of > the bongo .. bong!". > > Whereas i think it is beneficial to create a wider context so that > at least in certain forums different realities can be heard. > Not that it all ends up with AI rewriting any C or C++ code in > Rust, without any little human programmer getting paid for > anything of that rewrite, which does not fix just one logic error. > > [1] https://marc.info/?l=freebsd-hackers&m=172557660704363&w=2 > > Array bound checking, i mean, come on. Cheech and Chong are > beaners without that. That's a racial slur. Not cool. - Dan C. From tuhs at tuhs.org Tue Jan 6 13:52:53 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Tue, 06 Jan 2026 03:52:53 +0000 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: References: Message-ID: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> On Jan 5, 2026, at 09:15, Dan Cross wrote: > Does anyone have a copy of the paper mentioned in the subject? Wiley has the authoritative online copy (accessible via Sci-Hub) https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380181105 and Erica Fischer uploaded a scan to the Internet Archive https://archive.org/details/tale-of-two-greps Thalia From tuhs at tuhs.org Tue Jan 6 17:51:29 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 06 Jan 2026 00:51:29 -0700 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> Message-ID: <202601060751.6067pTMI079021@freefriends.org> Thalia Archibald via TUHS wrote: > On Jan 5, 2026, at 09:15, Dan Cross wrote: > > Does anyone have a copy of the paper mentioned in the subject? > > > Wiley has the authoritative online copy (accessible via Sci-Hub) > https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380181105 > and Erica Fischer uploaded a scan to the Internet Archive > https://archive.org/details/tale-of-two-greps > > Thalia > Thanks, that was an interesting read. Doug / Andrew -- is the fio library mentioned in the paper around anywhere? Or did it evolve into Plan 9's Bio library? Thanks, Arnold From tuhs at tuhs.org Tue Jan 6 18:32:13 2026 From: tuhs at tuhs.org (Noel Hunt via TUHS) Date: Tue, 6 Jan 2026 17:32:13 +0900 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: <202601060751.6067pTMI079021@freefriends.org> References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> <202601060751.6067pTMI079021@freefriends.org> Message-ID: You will find source in research editions from Eighth Edition on. It does seem that the bio library in Plan9 is an elaboration of fio. 2026年1月6日(火) 16:51 Arnold Robbins via TUHS : > Thalia Archibald via TUHS wrote: > > > On Jan 5, 2026, at 09:15, Dan Cross wrote: > > > Does anyone have a copy of the paper mentioned in the subject? > > > > > > Wiley has the authoritative online copy (accessible via Sci-Hub) > > https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380181105 > > and Erica Fischer uploaded a scan to the Internet Archive > > https://archive.org/details/tale-of-two-greps > > > > Thalia > > > > Thanks, that was an interesting read. > > Doug / Andrew -- is the fio library mentioned in the paper around > anywhere? Or did it evolve into Plan 9's Bio library? > > Thanks, > > Arnold > From tuhs at tuhs.org Tue Jan 6 21:48:33 2026 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Tue, 6 Jan 2026 12:48:33 +0100 Subject: [TUHS] Yacc binary on 4th edition tape Message-ID: Perusing the 4th edition archive I noticed that the usr/bin directory has a binary for Yacc. This reminded me of a project on my to-do list: recreating the yacc used at the Uni of Waterloo for their Thoth project. Unfortunately, there was no source for Yacc on the 4th edition tape. The oldest version I am aware of is the source as included with 6th edition. However, this looks quite promising. I offer the below timeline analysis for some sanity checking by the people who were there and have some specific questions at the end. For background: my interest is driven by an underlying interest in the “Eh” and “Zed” languages that evolved from B at the Uni of Waterloo. DMR mentions these languages in his paper on the history of C (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf). First on the timeline: - By 1970 there were B compilers written in B for the PDP-7, the GE600 / Honeywell 6000 and for the PDP-11. The GE compiler generated machine code, not threaded code (DMR writes "The most ambitious enterprise I undertook was a genuine cross-compiler that translated B to GE-635 machine instructions, not threaded code. It was a small tour de force: a full B compiler, written in its own language and generating code for a 36-bit mainframe, that ran on [the PDP-7, ] an 18-bit machine with 4K words of user address space.”). As the compiler was written in B, I assume this means that it next also ran on the GE itself. This compiler seems to have been the basis for the nascent C compilers (AAP writes "According to dmr's history of the C language NB had a machine code generator and ken told me (by email) that dmr's work on the code generator started on the Honeywell mainframe and that NB was always in machine code.” - http://squoze.net/NB/README). - DMR also writes in that paper: "By 1971, our miniature computer center was beginning to have users. We all wanted to create interesting software more easily. Using assembler was dreary enough that B, despite its performance problems, had been supplemented by a small library of useful service routines and was being used for more and more new programs. Among the more notable results of this period was Steve Johnson’s first version of the yacc parser-generator” So, Yacc first appears in 1971 and is written in B. As such, it ran on both the PDP-11 and the GE/Honeywell. - It is a guess, but I would hypothesize that the c0/c1 structure of the early 1972/1973 C compilers goes all the way back to the GE/Honeywell implementation of B. In this respect it is suggestive that the “last1120” C compiler names its passes "nc0" and “nc1”, following shortly on the transitional “new B” / “nb”. If true, it would stand to reason to assume that this mainframe B compiler also used a similar recursive descent / operator precedence parsing scheme. - The DMR history paper then goes on to say that Johnson had a sabbatical at the University of Waterloo in 1972, but I think this might be a slip of the pen. A Uni of Waterloo retrospective says that he arrived late in 1972 (“In August 1972, […] a new arrival was causing a stir in the Math & Computer building at University of Waterloo – a brand new Honeywell 6050 mainframe size computer. […] Shortly after the arrival of the Honeywell, Steve Johnson came to the Math Faculty on sabbatical from Bell Labs.”). He brought B and Yacc with him ("I suspect that few people realize his key role in introducing Bell Labs culture to University of Waterloo so early, including B Programming Language, getchar(), putchar(), the beginnings of the notion of software portability and, of course, yacc.”). https://randalljhoward.com/tag/dead-whale/ The year 1973 is also supported by a resume from 1982 ("I spent a 9-month Sabbatical in 1973 at the University of Waterloo, where I taught courses in Advanced Applications Techniques and Algebraic Manipulation.” — https://stacks.stanford.edu/file/druid:ws821cy1376/ws821cy1376.pdf). 1973 is also a better match with the internship of Alan Snyder in that year. - In an interview Johnson mentions "When YACC first ran, it was very slow […] I set out to improve the size and space characteristics. Over the next several years, I rewrote the program over a dozen times, speeding it up by a factor of 10,000 or so. Many of my speedups involved proving theorems that we could cut this or that corner and still have a valid parser. The introduction of precedence was one example of this.” (https://www.computerworld.com/article/1570304/yacc-unix-and-advice-from-bell-labs-alumni-stephen-johnson.html). I suspect that a fair bit of this improvement happened in 1972, because he continues with "Dennis was actively working on B while I was writing YACC. One day, I came in and YACC would not compile – it was out of space. It turns out that I had been using every single slot in the symbol table. The night before, Dennis had added the ‘for’ statement to B, and the word ‘for’ took a slot, so YACC no longer fit!”. This suggests 1972 much more than 1974 as the timeframe he had in mind when saying this. - This also tallies with DMR’s account, writing: "When Steve Johnson visited the University of Waterloo on sabbatical in 1972, he brought B with him. It became popular on the Honeywell machines there, and later spawned Eh and Zed (the Canadian answers to ‘what follows B?’). When Johnson returned to Bell Labs in 1973, he was disconcerted to find that the language whose seeds he brought to Canada had evolved back home; even his own yacc program had been rewritten in C, by Alan Snyder.”. As explained above, I think this should be read as “late 1972” and “late 1973”. So: a first, early C version of Yacc can be placed at mid 1973. - Alan Snyder did the Honeywell version of his portable compiler in 1973 (the PDP-10 version and his thesis are from 1975) (https://retrocomputingforum.com/t/some-materials-on-early-c-and-the-history-of-c/3016/2). This compiler used yacc, which implies that by (late) 1973 yacc must have been stable, fast and compact enough to handle a sizable grammar. I can understand converting it to nascent C, as I have recently found yacc to be a great compiler test input. In the timeline, this Snyder version is close to the binary on the 4th edition tape. - B evolved at Waterloo. Report CS-75-23 from September 1975 says "Current efforts center on the language ‘B' which is already implemented on the HIS 6050 and PDP 11; we hope to have a version of B for the Microdata before January, 1976. […] The problem is now reduced to that of recoding the B compiler code generation section and the basic I/O primitives.” And report CS-75-29 from November of that year says "The B compiler is well suited for our preliminary experimentation with portability because it is nicely structured and therefore easily modified to generate code for other machines. This is largely due to the fact that it is a syntax directed compiler for a language which has a simple and compact syntax. The one-pass compiler is implemented in B.” I assume “syntax directed” in this context to mean that the Honeywell B compiler was recoded to use Yacc for its parser - - somewhere between 1973 and 1975. If so, that effort probably used the B version of Yacc that Johnson brought in 1973. The 1976 Eh and the 1978 Zed compilers for sure use Yacc to build their parser. - All this makes the Yacc binary on the 4th edition tape interesting to me, as it gives a window on the state of Yacc late in 1973 when Johnson returned to Bell Labs. The binary appears truncated at the 16kb mark, but a first quick look at the strings suggests it is quite similar to the source code that is included with the surviving 6th edition Yacc source code. Similar, but not fully identical. This is in a context where the surviving 1975 Yacc source looks decidedly 1973 in style. For instance the yyparse function in file “parser.c” looks like a B function that has been minimally edited to make it early C - https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/yacc/lib/parser.c Another example is in y2.c, where in function “setup()” the “foutput" variable is set to -2 by default; I believe this to be a remnant from B on the Honeywell, where that means to output to the batch console. I wonder how much this 1975 yacc source has diverted from the 1973 Snyder B => C port; I presume not much. In fact, this version of Yacc proved quite easy to revert back to B (or Eh, actually): https://gitlab.com/pnru/Thoth/-/tree/master/user/yacc - An interesting sidetrack is the evolution of Johnson’s Yacc manual / paper. Several versions appear to exist, all a bit different. Later versions (1979 ?) have the “=“ sign before actions as an deprecated feature, but the 1975 source code still insists on the ‘=‘ sign. AAP appears to have the oldest version (1975?) of the document and this version still has the equals sign as mandatory in its text (http://squoze.net/UNIX/v6/files/doc/yacc.pdf). In 7th edition manual and code base the use of this ‘=‘ has become optional. I wonder when and why this change was made, the old syntax seems harmless. - The 6th edition Yacc has an optional optimizer pass, "/usr/yacc/yopti” which was optionally run after Yacc completed. As far as I can tell, the source for this optimiser is lost. I have found no materials explaining this optimizer pass. - Between 6th edition and 7th edition the code base changes substantially, presumably further compaction and speed-up. It grows from ~1700 to ~2200 lines. The optimizer pass is integrated into the base package, support for Ratfor is dropped, etc. The source also starts to look like ‘real C’. Alternatively, the yacc source in 6th edition might not reflect the latest internal Bell version and actual yacc development was perhaps more gradual. Although I use the 7th edition version in my C recreation of the Eh compiler, it does not seem like it is a good base to approximate what the Uni of Waterloo might have used in 1975-1977. Now for the questions: - Do the above timeline and assumptions sound correct (or at least plausible) to those who were there? - Does anybody know of Yacc source code older that what is included in 6th edition (other than attempting to reverse engineer the recently recovered 4th edition binary)? - Does anybody know more about the missing Yacc optimizer in 6th edition, what it did, etc.? Or is the only way to compare and contrast with 7th edition where the (that?) optimizer is integrated? From tuhs at tuhs.org Wed Jan 7 02:31:55 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Tue, 06 Jan 2026 16:31:55 +0000 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: References: Message-ID: <935F3594-ED2F-47D1-BEB5-A840045F9026@archibald.dev> Hi Paul, Excellent history on yacc and Waterloo! I’ll be adding your sources to my early UNIX history project :). I was aware of Wes Graham’s work on WATFOR at Waterloo and that the Computer Systems Group acquired UNIX in 1976 (which wasn’t necessarily the first group at Waterloo to do so), but I didn’t know of anything earlier. I found some interesting UNIX documents in the University of Waterloo archives and have uploaded them. https://archive.org/search?query=subject%3A%22University+of+Waterloo+Archives%22 Also, there are some items in the University of Waterloo Computer Museum that I’m hoping to get more information on, once I follow up with the curator. https://github.com/thaliaarchi/unix-history/blob/main/users/waterloo/butterworth.md > All this makes the Yacc binary on the 4th edition tape interesting to me, as it > gives a window on the state of Yacc late in 1973 when Johnson returned to Bell > Labs. The binary appears truncated at the 16kb mark If you’re using Angelo’s tar, you should fetch it again. He’s fixed some bugs that truncated several files, including yacc. http://squoze.net/UNIX/v4/unix_v4.tar Also you should know the tape dates to 12 June 1974, but the manual received was V4, so it’s V5 minus a week or so (though I only know that the V5 manual dates to the month of June). Although you could consider it a near-clean V5, I still call it V4, since the system was versioned by its manual. Thalia > On Jan 6, 2026, at 04:48, Paul Ruizendaal via TUHS wrote: > > > Perusing the 4th edition archive I noticed that the usr/bin directory has a binary for Yacc. This reminded me of a project on my to-do list: recreating the yacc used at the Uni of Waterloo for their Thoth project. Unfortunately, there was no source for Yacc on the 4th edition tape. The oldest version I am aware of is the source as included with 6th edition. However, this looks quite promising. > > I offer the below timeline analysis for some sanity checking by the people who were there and have some specific questions at the end. > > For background: my interest is driven by an underlying interest in the “Eh” and “Zed” languages that evolved from B at the Uni of Waterloo. DMR mentions these languages in his paper on the history of C (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf). > > First on the timeline: > > - By 1970 there were B compilers written in B for the PDP-7, the GE600 / Honeywell 6000 and for the PDP-11. The GE compiler generated machine code, not threaded code (DMR writes "The most ambitious enterprise I undertook was a genuine cross-compiler that > translated B to GE-635 machine instructions, not threaded code. It was a small tour de force: a full B compiler, written in its own language and generating code for a 36-bit mainframe, that ran on [the PDP-7, ] an 18-bit machine with 4K words of user address space.”). As the compiler was written in B, I assume this means that it next also ran on the GE itself. This compiler seems to have been the basis for the nascent C compilers (AAP writes "According to dmr's history of the C language NB had a machine code generator and ken told me (by email) that dmr's work on the code generator started on the Honeywell mainframe and that NB was always in machine code.” - http://squoze.net/NB/README). > > - DMR also writes in that paper: "By 1971, our miniature computer center was beginning to have users. We all wanted to create interesting software more easily. Using assembler was dreary enough that B, despite its performance problems, had been supplemented by a small library of useful service routines and was being used for more and more new programs. Among the more notable results of this period was Steve Johnson’s first version of the yacc parser-generator” So, Yacc first appears in 1971 and is written in B. As such, it ran on both the PDP-11 and the GE/Honeywell. > > - It is a guess, but I would hypothesize that the c0/c1 structure of the early 1972/1973 C compilers goes all the way back to the GE/Honeywell implementation of B. In this respect it is suggestive that the “last1120” C compiler names its passes "nc0" and “nc1”, following shortly on the transitional “new B” / “nb”. If true, it would stand to reason to assume that this mainframe B compiler also used a similar recursive descent / operator precedence parsing scheme. > > - The DMR history paper then goes on to say that Johnson had a sabbatical at the University of Waterloo in 1972, but I think this might be a slip of the pen. A Uni of Waterloo retrospective says that he arrived late in 1972 (“In August 1972, […] a new arrival was causing a stir in the Math & Computer building at University of Waterloo – a brand new Honeywell 6050 mainframe size computer. […] Shortly after the arrival of the Honeywell, Steve Johnson came to the Math Faculty on sabbatical from Bell Labs.”). He brought B and Yacc with him ("I suspect that few people realize his key role in introducing Bell Labs culture to University of Waterloo so early, including B Programming Language, getchar(), putchar(), the beginnings of the notion of software portability and, of course, yacc.”). https://randalljhoward.com/tag/dead-whale/ The year 1973 is also supported by a resume from 1982 ("I spent a 9-month Sabbatical in 1973 at the University of Waterloo, where I taught courses in Advanced Applications Techniques and Algebraic Manipulation.” — https://stacks.stanford.edu/file/druid:ws821cy1376/ws821cy1376.pdf). 1973 is also a better match with the internship of Alan Snyder in that year. > > - In an interview Johnson mentions "When YACC first ran, it was very slow […] I set out to improve the size and space characteristics. Over the next several years, I rewrote the program over a dozen times, speeding it up by a factor of 10,000 or so. Many of my speedups involved proving theorems that we could cut this or that corner and still have a valid parser. The introduction of precedence was one example of this.” (https://www.computerworld.com/article/1570304/yacc-unix-and-advice-from-bell-labs-alumni-stephen-johnson.html). I suspect that a fair bit of this improvement happened in 1972, because he continues with "Dennis was actively working on B while I was writing YACC. One day, I came in and YACC would not compile – it was out of space. It turns out that I had been using every single slot in the symbol table. The night before, Dennis had added the ‘for’ statement to B, and the word ‘for’ took a slot, so YACC no longer fit!”. This suggests 1972 much more than 1974 as the timeframe he had in mind when saying this. > > - This also tallies with DMR’s account, writing: "When Steve Johnson visited the University of Waterloo on sabbatical in 1972, he brought B with him. It became popular on the Honeywell machines there, and later spawned Eh and Zed (the Canadian answers to ‘what follows B?’). When Johnson returned to Bell Labs in 1973, he was disconcerted to find that the language whose seeds he brought to Canada had evolved back home; even his own yacc program had been rewritten in C, by Alan Snyder.”. As explained above, I think this should be read as “late 1972” and “late 1973”. So: a first, early C version of Yacc can be placed at mid 1973. > > - Alan Snyder did the Honeywell version of his portable compiler in 1973 (the PDP-10 version and his thesis are from 1975) (https://retrocomputingforum.com/t/some-materials-on-early-c-and-the-history-of-c/3016/2). This compiler used yacc, which implies that by (late) 1973 yacc must have been stable, fast and compact enough to handle a sizable grammar. I can understand converting it to nascent C, as I have recently found yacc to be a great compiler test input. In the timeline, this Snyder version is close to the binary on the 4th edition tape. > > - B evolved at Waterloo. Report CS-75-23 from September 1975 says "Current efforts center on the language ‘B' which is already implemented on the HIS 6050 and PDP 11; we hope to have a version of B for the Microdata before January, 1976. […] The problem is now reduced to that of recoding the B compiler code generation section and the basic I/O primitives.” And report CS-75-29 from November of that year says "The B compiler is well suited for our preliminary experimentation with portability because it is nicely structured and therefore easily modified to generate code for other machines. This is largely due to the fact that it is a syntax directed compiler for a language which has a simple and compact syntax. The one-pass compiler is implemented in B.” I assume “syntax directed” in this context to mean that the Honeywell B compiler was recoded to use Yacc for its parser - - somewhere between 1973 and 1975. If so, that effort probably used the B version of Yacc that Johnson brought in 1973. The 1976 Eh and the 1978 Zed compilers for sure use Yacc to build their parser. > > - All this makes the Yacc binary on the 4th edition tape interesting to me, as it gives a window on the state of Yacc late in 1973 when Johnson returned to Bell Labs. The binary appears truncated at the 16kb mark, but a first quick look at the strings suggests it is quite similar to the source code that is included with the surviving 6th edition Yacc source code. Similar, but not fully identical. This is in a context where the surviving 1975 Yacc source looks decidedly 1973 in style. For instance the yyparse function in file “parser.c” looks like a B function that has been minimally edited to make it early C - https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/yacc/lib/parser.c Another example is in y2.c, where in function “setup()” the “foutput" variable is set to -2 by default; I believe this to be a remnant from B on the Honeywell, where that means to output to the batch console. > > I wonder how much this 1975 yacc source has diverted from the 1973 Snyder B => C port; I presume not much. In fact, this version of Yacc proved quite easy to revert back to B (or Eh, actually): https://gitlab.com/pnru/Thoth/-/tree/master/user/yacc > > - An interesting sidetrack is the evolution of Johnson’s Yacc manual / paper. Several versions appear to exist, all a bit different. Later versions (1979 ?) have the “=“ sign before actions as an deprecated feature, but the 1975 source code still insists on the ‘=‘ sign. AAP appears to have the oldest version (1975?) of the document and this version still has the equals sign as mandatory in its text (http://squoze.net/UNIX/v6/files/doc/yacc.pdf). In 7th edition manual and code base the use of this ‘=‘ has become optional. I wonder when and why this change was made, the old syntax seems harmless. > > - The 6th edition Yacc has an optional optimizer pass, "/usr/yacc/yopti” which was optionally run after Yacc completed. As far as I can tell, the source for this optimiser is lost. I have found no materials explaining this optimizer pass. > > - Between 6th edition and 7th edition the code base changes substantially, presumably further compaction and speed-up. It grows from ~1700 to ~2200 lines. The optimizer pass is integrated into the base package, support for Ratfor is dropped, etc. The source also starts to look like ‘real C’. Alternatively, the yacc source in 6th edition might not reflect the latest internal Bell version and actual yacc development was perhaps more gradual. Although I use the 7th edition version in my C recreation of the Eh compiler, it does not seem like it is a good base to approximate what the Uni of Waterloo might have used in 1975-1977. > > Now for the questions: > > - Do the above timeline and assumptions sound correct (or at least plausible) to those who were there? > > - Does anybody know of Yacc source code older that what is included in 6th edition (other than attempting to reverse engineer the recently recovered 4th edition binary)? > > - Does anybody know more about the missing Yacc optimizer in 6th edition, what it did, etc.? Or is the only way to compare and contrast with 7th edition where the (that?) optimizer is integrated? > > > > From tuhs at tuhs.org Wed Jan 7 02:32:56 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 06 Jan 2026 16:32:56 +0000 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> Message-ID: Years ago when working at Johns Hopkins where finding ways to crash or otherwise compromise the UNIX system was sport, I spent a lot of time on the student staff there finding things and fixing them. Buffer overruns were a frequent cause of crashes. And it wasn’t even just user programs that were the problem. There’s a quaint bug in the PDP-11 where that if you fill up your entire 64K user address space with spl instructions, you lock up the machine. Now it was a quaint exercise to the student, to write a program that would fill up your program (complete with overwriting the stack) to make that happen. Being a lazy sort, I looked for a different solution. Well, our kernel had this system call called “nostack” which was used to get rid of UNIX’s idea of stack managment (this was done so we could emulate RSTS and run RSTS Basic under UNIX, the one condition that the department leveled on us to switch away from RSTS). So, I turned off the UNIX stack and then tried to change the break to 64K. This worked … for a few minutes. Then the machine crashed with a kernel panic with hardware errors. This wasn’t the crash I was expecting (the spl gambit just locks the mahcine so that not even the halt key works) and I’d not even started writing the data. Of course, now I had to deal with fixing the bug. Turns out that the error came from the SWAP DEVICE (an RF-11 fixed head disk in our case). Turns out it had found zero bytes of memory somewhere that didn’t exist and tried to swap 64K bytes into it. Since the RF-11 does NPR (what PDP-11s call DMA), the failure is reported by the disk controller. But more fun was had by using up other resources other than memory. An early UNIX security exploit was to open up all the file descriptors allowed and then invoke “su.” Su figured that something must really be wrong if it failed to open /etc/passwd and just gave you a root shell anyhow. Another fd exploit was to close certain file descriptors before invoking setuid programs. I found this when fixing a user’s mounted diskpack which I found had the output of mount written over the superblock. Turns out he wanted to get rid of the message mount printed, so he just closed file descriptor 1. Our mount program opened up the raw disk to read the pack labels (it hadn’t yet been moved to the kernel), and so his output got written there. Why the disk wasn’t opened RO was just sloppiness. Having found this, I launched into trying other user-executable set uid programs for similar bugs. Found a efw, but late in the night decided to give it up and go home. Coming in the next day I perused the (paper) logbook we kept of all crashes/reboot. I found an entry that said the system was shutdown to restoree the accounting file that had the first 8 bytes corrupted. Hmm… I say. I think I know how that happened. The other system admin said, “I figured you did. It was your user name that was the corrupting data (plus a colon). -Ron From tuhs at tuhs.org Wed Jan 7 03:46:56 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Tue, 6 Jan 2026 09:46:56 -0800 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: <935F3594-ED2F-47D1-BEB5-A840045F9026@archibald.dev> References: <935F3594-ED2F-47D1-BEB5-A840045F9026@archibald.dev> Message-ID: <431a6d9d-f1e4-c356-28ec-f87bb6abf3f2@bitsavers.org> On 1/6/26 8:31 AM, Thalia Archibald via TUHS wrote: > Also, there are some items in the University of Waterloo Computer Museum that > I’m hoping to get more information on, once I follow up with the curator. > https://github.com/thaliaarchi/unix-history/blob/main/users/waterloo/butterworth.md I would really be interested if any of Thoth software has survived there. Nothing is known to exist of Cheriton's UBC version From tuhs at tuhs.org Wed Jan 7 05:17:14 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 6 Jan 2026 14:17:14 -0500 Subject: [TUHS] salami slicing, was Buffer overflow found/fixed in v4 tape ; ) In-Reply-To: References: <97fe5ae9-5080-126a-60c9-c1cfceaa58f9@makerlisp.com> Message-ID: <20260106191714.4E993EF3CBE8@ary.qy> It appears that Paul Winalski via TUHS said: >The audit department at one of Hartford's major insurance companies >received a phone call. It was from the head of the local BMW dealership. >He told them, "One of your IT workers just paid cash for a top-of-the-line >BMW. We thought you'd like to know that." It turns out that the IT worker >was the programmer responsible for maintaining the program that prints the >paychecks. The weekly pay calculation often yielded amounts in fractions >of pennies. These were either rounded up or down to the nearest cent. The >fractional pennies were tracked in an account called the breakage account. >This programmer had created a fake employee in the company's computer >records and had a check printed for that "person" containing the amount of >money in the breakage account. He had been doing this for some time and >had embezzled enough money to pay cash for a top-end Beemer. It's a swell story, but it's an urban legend told in many different varieties. https://www.snopes.com/fact-check/the-salami-technique/ R's, John From tuhs at tuhs.org Thu Jan 1 01:54:43 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Wed, 31 Dec 2025 10:54:43 -0500 Subject: [TUHS] Photo of old Unix manuals Message-ID: Attached is a photo of all the Research manuals. Top row v1-v5 (note the original owner's name on v1 and v2) Middle row v6 (2 vols), v7 (3 vols) Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) Doug From tuhs at tuhs.org Wed Jan 7 08:59:21 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Tue, 06 Jan 2026 23:59:21 +0100 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: <20260106225921.HccRTfPk@steffen%sdaoden.eu> Douglas McIlroy via TUHS wrote in : |Attached is a photo of all the Research manuals. |Top row v1-v5 (note the original owner's name on v1 and v2) |Middle row v6 (2 vols), v7 (3 vols) |Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) TUHS does not let images pass. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Wed Jan 7 09:25:32 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Wed, 07 Jan 2026 00:25:32 +0100 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: <20260106225921.HccRTfPk@steffen%sdaoden.eu> References: <20260106225921.HccRTfPk@steffen%sdaoden.eu> Message-ID: <20260106232532.eU6Q3FYy@steffen%sdaoden.eu> Steffen Nurpmeso via TUHS wrote in <20260106225921.HccRTfPk at steffen%sdaoden.eu>: |Douglas McIlroy via TUHS wrote in | : ||Attached is a photo of all the Research manuals. ||Top row v1-v5 (note the original owner's name on v1 and v2) ||Middle row v6 (2 vols), v7 (3 vols) ||Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) | |TUHS does not let images pass. However i am very unfriendly, and even stupid, as it was meant as a quick note in private as opposed to what actually happened. For a very quick shot https://pasteboard.co/ seems to be a freely available and working share service for images (via browser) that i now quicky discovered as the one i had used several times in the past seems to go offline. Select a file on the local disc from within the browser, and they give an URL under which the image can be accessed. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Wed Jan 7 09:54:06 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Wed, 7 Jan 2026 10:54:06 +1100 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: References: Message-ID: On Tue, Jan 06, 2026 at 12:48:33PM +0100, Paul Ruizendaal via TUHS wrote: > - The DMR history paper then goes on to say that Johnson had a > sabbatical at the University of Waterloo in 1972, but I think this > might be a slip of the pen. A Uni of Waterloo retrospective says > that he arrived late in 1972 (“In August 1972, […] a new arrival > was causing a stir in the Math & Computer building at University > of Waterloo – a brand new Honeywell 6050 mainframe size computer. > […] Shortly after the arrival of the Honeywell, Steve Johnson came > to the Math Faculty on sabbatical from Bell Labs.”). He brought B > and Yacc with him ("I suspect that few people realize his key role > in introducing Bell Labs culture to University of Waterloo so early, > including B Programming Language, getchar(), putchar(), the beginnings > of the notion of software portability and, of course, yacc.”). > https://randalljhoward.com/tag/dead-whale/ The year 1973 is also > supported by a resume from 1982 ("I spent a 9-month Sabbatical in > 1973 at the University of Waterloo, where I taught courses in > Advanced Applications Techniques and Algebraic Manipulation.” — > https://stacks.stanford.edu/file/druid:ws821cy1376/ws821cy1376.pdf). > 1973 is also a better match with the internship of Alan Snyder in > that year. "sabbatical in 1973, from January to September" Steve Johnson in: Salus - A Quarter Century of UNIX, p 100 From tuhs at tuhs.org Wed Jan 7 10:32:48 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 7 Jan 2026 10:32:48 +1000 Subject: [TUHS] Unix 4.0? Message-ID: Strangely, I was just browsing through the Unix Archive here and came cross https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ For those looking for a reference guide, there is one here which is a flip book with six holes for binding at the top. It names itself "UNIX Reference Guide Release 4.0" and is dated April 1981. So this isn't 4th Edition :-) Is this release 4.0 of the reference guide, or does the 4.0 refer the version of Unix. I'm confused! Cheers, Warren From tuhs at tuhs.org Wed Jan 7 10:35:57 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Wed, 7 Jan 2026 11:35:57 +1100 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> References: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> Message-ID: Thanks, I hadn't considered blank pages. Of the missing pages in the scan (4, 6, 18) only page 6 (chgrp to du) is listed in the contents. The reference card is not often discussed, but as far as I can tell there was only one edition in 1979. So it seems likely you have the same one as Clem. On Sun, Jan 04, 2026 at 12:07:07PM -0800, Mary Ann Horton via TUHS wrote: > I also have a copy of Cherry's booklet (spiral bound, 1979) in my > collection. > > Comparing it with the incompete chilton scan, it's only missing pages 4 and > 22. The other missing pages are blank. > > I gather this is the same one Clem has? If not, let me know and I'll scan > it. > > Thanks, > > /Mary Ann Horton/ (she/her/ma'am) >       Award Winning Author > maryannhorton.com > > > > On 1/3/26 20:41, Jonathan Gray via TUHS wrote: > > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > Also, while looking for the vi cards, I turned up two wonderful artifacts > > > that I'll try to get scanned and added to TUHS at some point. When you > > > purchased V7 from AT&T, you got one copy of the printed docs and a small > > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > > similar but different. > > Was the first edition also distributed to V6 licensees? > > > > -- > > > > UNIX Reference Card - First Edition > > L. L. Cherry > > September, 1975 > > A handy guide to UNIX commands and syntax. > > > > mentioned in: > > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > > v10/doc/bibliog.a unpm-docs > > > > -- > > > > UNIX Reference Card > > distributed by > > Computing Information Service > > BELL LABORATORIES > > Murray Hill, N. J. 07974 > > compiled by Lorinda Cherry > > Second Edition, March 1979 > > > > incomplete scan, some pages missing: > > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > > viahttp://www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > > > CHM has a copy, not currently scanned > > https://www.computerhistory.org/collections/catalog/102632799/ > > > > spiral bound > > https://www.flickr.com/photos/n1kdo/53136436051 > > comb bound > > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 From tuhs at tuhs.org Wed Jan 7 10:37:31 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 7 Jan 2026 10:37:31 +1000 Subject: [TUHS] Unix 4.0? In-Reply-To: References: Message-ID: On Wed, Jan 07, 2026 at 10:32:48AM +1000, Warren Toomey via TUHS wrote: > Strangely, I was just browsing through the Unix Archive here and came > cross https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ Ah, I should read the README. And a Google search found this: https://wiki.tuhs.org/doku.php?id=systems:unixts4 Apologies for the false alarm :-) Warren From tuhs at tuhs.org Wed Jan 7 11:41:13 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 6 Jan 2026 20:41:13 -0500 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> Message-ID: Agreed I’ll try to push doing some scans up onto the TUHS archived a big farther up my ToDo list. Sent from a handheld expect more typos than usual On Tue, Jan 6, 2026 at 7:36 PM Jonathan Gray via TUHS wrote: > Thanks, I hadn't considered blank pages. Of the missing pages in the scan > (4, 6, 18) only page 6 (chgrp to du) is listed in the contents. > > The reference card is not often discussed, but as far as I can tell there > was > only one edition in 1979. So it seems likely you have the same one as > Clem. > > On Sun, Jan 04, 2026 at 12:07:07PM -0800, Mary Ann Horton via TUHS wrote: > > I also have a copy of Cherry's booklet (spiral bound, 1979) in my > > collection. > > > > Comparing it with the incompete chilton scan, it's only missing pages 4 > and > > 22. The other missing pages are blank. > > > > I gather this is the same one Clem has? If not, let me know and I'll scan > > it. > > > > Thanks, > > > > /Mary Ann Horton/ (she/her/ma'am) > > Award Winning Author > > maryannhorton.com > > > > > > > > On 1/3/26 20:41, Jonathan Gray via TUHS wrote: > > > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > > Also, while looking for the vi cards, I turned up two wonderful > artifacts > > > > that I'll try to get scanned and added to TUHS at some point. When > you > > > > purchased V7 from AT&T, you got one copy of the printed docs and a > small > > > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > > > compiled. Also, when DEC released V7M-11, they printed a small > flip-binding > > > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > > > similar but different. > > > Was the first edition also distributed to V6 licensees? > > > > > > -- > > > > > > UNIX Reference Card - First Edition > > > L. L. Cherry > > > September, 1975 > > > A handy guide to UNIX commands and syntax. > > > > > > mentioned in: > > > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > > > v10/doc/bibliog.a unpm-docs > > > > > > -- > > > > > > UNIX Reference Card > > > distributed by > > > Computing Information Service > > > BELL LABORATORIES > > > Murray Hill, N. J. 07974 > > > compiled by Lorinda Cherry > > > Second Edition, March 1979 > > > > > > incomplete scan, some pages missing: > > > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > > > viahttp:// > www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > > > > > CHM has a copy, not currently scanned > > > https://www.computerhistory.org/collections/catalog/102632799/ > > > > > > spiral bound > > > https://www.flickr.com/photos/n1kdo/53136436051 > > > comb bound > > > > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 > From tuhs at tuhs.org Wed Jan 7 11:59:06 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Tue, 6 Jan 2026 20:59:06 -0500 Subject: [TUHS] Photo of old Unix manuals Message-ID: Sorry, I thought the referenced attachment would be replaced by a link to a saved copy as happens with some attachments, but it turns out to exceed the tuhs size limit. it's now at https://www.cs.dartmouth.edu/~doug/UnixManuals.jpg. In case anyone is wondering, the only printed form of v10 was the trade binding. Only v6, v7 (non-trade), and v10 included extra volumes of companion documents. Doug. Date: Wed, 31 Dec 2025 10:54:43 -0500 From: Douglas McIlroy Subject: [TUHS] Re: Photo of old Unix manuals To: TUHS main list Attached is a photo of all the Research manuals. Top row v1-v5 (note the original owner's name on v1 and v2) Middle row v6 (2 vols), v7 (3 vols) Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) From tuhs at tuhs.org Wed Jan 7 12:03:08 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Wed, 07 Jan 2026 02:03:08 +0000 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: <92221366-C4F4-40F2-BBDA-7C8FD2B67157@archibald.dev> Douglas McIlroy wrote: > Attached is a photo of all the Research manuals. > Top row v1-v5 (note the original owner's name on v1 and v2) > Middle row v6 (2 vols), v7 (3 vols) > Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) And with Bob Morris’ “V0” manual, you have that too :) Thalia From tuhs at tuhs.org Wed Jan 7 12:39:54 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 07 Jan 2026 02:39:54 +0000 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: On Saturday, January 3rd, 2026 at 20:42, Jonathan Gray via TUHS wrote: > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > Also, while looking for the vi cards, I turned up two wonderful artifacts > > that I'll try to get scanned and added to TUHS at some point. When you > > purchased V7 from AT&T, you got one copy of the printed docs and a small > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > similar but different. > > > Was the first edition also distributed to V6 licensees? > > -- > > UNIX Reference Card - First Edition > L. L. Cherry > September, 1975 > A handy guide to UNIX commands and syntax. > > mentioned in: > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > v10/doc/bibliog.a unpm-docs > > -- This is now scanned, albeit from a photocopy unknown generations removed and without covers or title page. It ain't great but should be good enough until a real one gets scanned without generational fuzz. https://archive.org/details/unix-reference-card-first-edition Page 23 (22 in PDF) concerns site dependent commands, most of which concern networking with other systems like IBM and GE/Honeywell stuff. The references in the end date this to the Sixth Edition. There is a blacked-out bit in the TROFF User's Manual reference, I can't quite make it out, it was in previous generations of whatever scan this came from but I can make out a 127 and a 4 I believe, it's probably a crossed out memorandum number. With the Second Edition distributed with V7, and another issue produced for Release 4.0, I now wonder how many other variations on this were made. There is a yellow fan-fold "Quick Guide" from 1982 by, like the yellow-covered comb-bound handbooks, Morris Bolsky. A later edition then appears in 1987, same by-line. Speaking of the ex/vi card that spurred this conversation, AT&T had their own variant, issue 2 here: https://archive.org/details/unix-system-v-visual-editor-quick-reference-issue-2 - Matt G. From tuhs at tuhs.org Wed Jan 7 13:10:55 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 7 Jan 2026 13:10:55 +1000 Subject: [TUHS] UNIX Reference Card In-Reply-To: References: Message-ID: On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > Also, while looking for the vi cards, I turned up two wonderful artifacts > that I'll try to get scanned and added to TUHS at some point. When you > purchased V7 from AT&T, you got one copy of the printed docs and a small > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > similar but different. On Wed, Jan 07, 2026 at 02:39:54AM +0000, segaloco via TUHS wrote: > This is now scanned, albeit from a photocopy unknown generations removed > and without covers or title page. It ain't great but should be good > enough until a real one gets scanned without generational fuzz. > > https://archive.org/details/unix-reference-card-first-edition > > The references in the end date this to the Sixth Edition. There is a > blacked-out bit in the TROFF User's Manual reference, I can't quite make > it out, it was in previous generations of whatever scan this came from > but I can make out a 127 and a 4 I believe, it's probably a crossed out > memorandum number. I've just added it to the Archive here: https://www.tuhs.org/Archive/Documentation/Cards/ Thanks! Warren From tuhs at tuhs.org Wed Jan 7 13:27:59 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Wed, 7 Jan 2026 14:27:59 +1100 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: Message-ID: On Wed, Jan 07, 2026 at 02:39:54AM +0000, segaloco via TUHS wrote: > On Saturday, January 3rd, 2026 at 20:42, Jonathan Gray via TUHS wrote: > > > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > > > Also, while looking for the vi cards, I turned up two wonderful artifacts > > > that I'll try to get scanned and added to TUHS at some point. When you > > > purchased V7 from AT&T, you got one copy of the printed docs and a small > > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > > compiled. Also, when DEC released V7M-11, they printed a small flip-binding > > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > > similar but different. > > > > > > Was the first edition also distributed to V6 licensees? > > > > -- > > > > UNIX Reference Card - First Edition > > L. L. Cherry > > September, 1975 > > A handy guide to UNIX commands and syntax. > > > > mentioned in: > > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > > v10/doc/bibliog.a unpm-docs > > > > -- > > This is now scanned, albeit from a photocopy unknown generations removed > and without covers or title page. It ain't great but should be good > enough until a real one gets scanned without generational fuzz. > > https://archive.org/details/unix-reference-card-first-edition > > Page 23 (22 in PDF) concerns site dependent commands, most of which > concern networking with other systems like IBM and GE/Honeywell stuff. > > The references in the end date this to the Sixth Edition. There is a > blacked-out bit in the TROFF User's Manual reference, I can't quite make > it out, it was in previous generations of whatever scan this came from > but I can make out a 127 and a 4 I believe, it's probably a crossed out > memorandum number. Thanks for the scan. I wonder if the cover was as fun as the 1979 one. It isn't quite Sixth Edition as distributed externally. It mentions man, troff and even sed. Also access() and alarm() system calls which were part of the "50 changes" tape. From tuhs at tuhs.org Wed Jan 7 16:24:02 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 06 Jan 2026 23:24:02 -0700 Subject: [TUHS] Unix 4.0? In-Reply-To: References: Message-ID: <202601070624.6076O2j1078296@freefriends.org> Hi Warren, Warren Toomey via TUHS wrote: > Strangely, I was just browsing through the Unix Archive here and came > cross https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/ > > For those looking for a reference guide, there is one here which is a > flip book with six holes for binding at the top. It names itself > "UNIX Reference Guide Release 4.0" and is dated April 1981. > > So this isn't 4th Edition :-) Is this release 4.0 of the reference > guide, or does the 4.0 refer the version of Unix. I'm confused! > > Cheers, Warren It refers to Unix 4.0. This version was between System III and System V and wasn't released externally. I've told this story before, but I guess telling it again once every few years doesn't hurt. ;-) In 1981 I did some contract C programming at Southern Bell on a PDP-11/70 running Unix 4.0; that scan is from my copy. The other Unix 4.0 docs are from photocopies I made of the docs over the course of that summer. When I asked about the difference between System III and Unix 4.0, I was told that AT&T publicly released one version behind what they were running internally. With System V, they decided to change that policy, which is why there never was a System IV. They did not do a separate Reference Manual (Sections 1-8) for Unix 4.0; they gave me the manual for Unix 3.0 (comb bound) and there was a doc that summarized the differences. One of the things that still sticks out in my mind is the statement The "destroy your input file" feature of sort is now gone. Apparently, if you had done sort -o file-x file-x file-y file-z sort would have opened and truncated file-x for output before opening it for input. Ooops! :-) HTH, Arnold From tuhs at tuhs.org Wed Jan 7 17:44:05 2026 From: tuhs at tuhs.org (William H. Mitchell via TUHS) Date: Wed, 7 Jan 2026 00:44:05 -0700 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: I see "Ossanna" on the first and second edition manuals; perhaps those were his copies. I remember Ralph Griswold reverently talking about Joe Ossanna. > On Jan 6, 2026, at 6:59 PM, Douglas McIlroy via TUHS wrote: > > Sorry, I thought the referenced attachment would be replaced > by a link to a saved copy as happens with some attachments, > but it turns out to exceed the tuhs size limit. it's now at > https://www.cs.dartmouth.edu/~doug/UnixManuals.jpg. > In case anyone is wondering, the only printed form of v10 was > the trade binding. Only v6, v7 (non-trade), and v10 included > extra volumes of companion documents. > > Doug. > > Date: Wed, 31 Dec 2025 10:54:43 -0500 > From: Douglas McIlroy > Subject: [TUHS] Re: Photo of old Unix manuals > To: TUHS main list > > Attached is a photo of all the Research manuals. > Top row v1-v5 (note the original owner's name on v1 and v2) > Middle row v6 (2 vols), v7 (3 vols) > Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) From tuhs at tuhs.org Wed Jan 7 18:48:57 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 07 Jan 2026 01:48:57 -0700 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: <202601070848.6078mvHu097827@freefriends.org> Hi Doug. Douglas McIlroy via TUHS wrote: > Sorry, I thought the referenced attachment would be replaced > by a link to a saved copy as happens with some attachments, > but it turns out to exceed the tuhs size limit. it's now at > https://www.cs.dartmouth.edu/~doug/UnixManuals.jpg. > In case anyone is wondering, the only printed form of v10 was > the trade binding. Only v6, v7 (non-trade), and v10 included > extra volumes of companion documents. > > Doug. Are there any manuals that you have that have not been scanned? v2? v3? The trade pub V7 was in a local bookstore for a while, but expensive. I'm sorry now that I didn't buy it. Courtesy of BWK I have a V8 manual, and I bought a V9 manual from Bell Labs sometime in the early 90s. I remember you sending me an email that you had to check if you could sell one to me. It was like $50. I bought the V10 manuals when they came out, and I also have the published Plan 9 manuals. :-) Arnold From tuhs at tuhs.org Wed Jan 7 19:00:07 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 07 Jan 2026 02:00:07 -0700 Subject: [TUHS] [off topic] Advocating for free information Message-ID: <202601070900.607907wn098699@freefriends.org> [ Sent to TUHS and bcc'ed to a number of friends. ] Hi All. This may be of interest to the list. I ask Warren's forgiveness for posting something off topic, and I respectfully request that we DON'T start a discussion about it. Thanks, Arnold > Date: Tue, 6 Jan 2026 20:32:47 -0500 (EST) > From: Terence Kelly > To: Arnold Robbins > Subject: advocating for free information > > Hi Arnold, > > [...] > > Briefly, the ACM Digital Library (DL) celebrated the holidays by revoking > public access to crucial facilities that have long been freely available > to all. Anyone not affiliated with a posh institution is locked out. > Free Software developers, scrappy startup coders, and penniless students > at nearly every community college in the US are locked out. > > To date, academics have spoken out against the new DL paywall... > > https://www.ipetitions.com/petition/restore-fully-free-and-open-access > > ...but news of the paywall has not yet reached the Free Software > community. > > I'd be grateful if you could forward the above petition URL to friends in > the Free Software world. Samizdat is the best way to spread news like > this. And of course, I and like-minded people would be honored if you > signed. > > Thanks & Happy New Year! > > -- Terence From tuhs at tuhs.org Wed Jan 7 19:14:05 2026 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Wed, 7 Jan 2026 10:14:05 +0100 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: <935F3594-ED2F-47D1-BEB5-A840045F9026@archibald.dev> References: <935F3594-ED2F-47D1-BEB5-A840045F9026@archibald.dev> Message-ID: <03F70796-1BB5-44DD-AAD1-1D56B9A2FEEA@planet.nl> Thank you for these clarifications. Refetching the v4 archive indeed brings a complete yacc binary, and it is unstripped. I guess at some point I need to find a tool that can disassemble a PDP-11 a.out file, taking into account the symbols. Indeed, the tape is from 1974, not 1973 — which makes quite a difference as things were moving fast in that era — but still closer to the B version than the yacc sources in v6. Thank you for highlighting this. Paul > On 6 Jan 2026, at 17:31, Thalia Archibald wrote: > > Hi Paul, > > Excellent history on yacc and Waterloo! I’ll be adding your sources to my early > UNIX history project :). > > I was aware of Wes Graham’s work on WATFOR at Waterloo and that the Computer > Systems Group acquired UNIX in 1976 (which wasn’t necessarily the first group at > Waterloo to do so), but I didn’t know of anything earlier. I found some > interesting UNIX documents in the University of Waterloo archives and have > uploaded them. > https://archive.org/search?query=subject%3A%22University+of+Waterloo+Archives%22 > > Also, there are some items in the University of Waterloo Computer Museum that > I’m hoping to get more information on, once I follow up with the curator. > https://github.com/thaliaarchi/unix-history/blob/main/users/waterloo/butterworth.md > >> All this makes the Yacc binary on the 4th edition tape interesting to me, as it >> gives a window on the state of Yacc late in 1973 when Johnson returned to Bell >> Labs. The binary appears truncated at the 16kb mark > > > If you’re using Angelo’s tar, you should fetch it again. He’s fixed some bugs > that truncated several files, including yacc. > http://squoze.net/UNIX/v4/unix_v4.tar > > Also you should know the tape dates to 12 June 1974, but the manual received was > V4, so it’s V5 minus a week or so (though I only know that the V5 manual dates > to the month of June). Although you could consider it a near-clean V5, I still > call it V4, since the system was versioned by its manual. > > Thalia > >> On Jan 6, 2026, at 04:48, Paul Ruizendaal via TUHS wrote: >> >> >> Perusing the 4th edition archive I noticed that the usr/bin directory has a binary for Yacc. This reminded me of a project on my to-do list: recreating the yacc used at the Uni of Waterloo for their Thoth project. Unfortunately, there was no source for Yacc on the 4th edition tape. The oldest version I am aware of is the source as included with 6th edition. However, this looks quite promising. >> >> I offer the below timeline analysis for some sanity checking by the people who were there and have some specific questions at the end. >> >> For background: my interest is driven by an underlying interest in the “Eh” and “Zed” languages that evolved from B at the Uni of Waterloo. DMR mentions these languages in his paper on the history of C (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf). >> >> First on the timeline: >> >> - By 1970 there were B compilers written in B for the PDP-7, the GE600 / Honeywell 6000 and for the PDP-11. The GE compiler generated machine code, not threaded code (DMR writes "The most ambitious enterprise I undertook was a genuine cross-compiler that >> translated B to GE-635 machine instructions, not threaded code. It was a small tour de force: a full B compiler, written in its own language and generating code for a 36-bit mainframe, that ran on [the PDP-7, ] an 18-bit machine with 4K words of user address space.”). As the compiler was written in B, I assume this means that it next also ran on the GE itself. This compiler seems to have been the basis for the nascent C compilers (AAP writes "According to dmr's history of the C language NB had a machine code generator and ken told me (by email) that dmr's work on the code generator started on the Honeywell mainframe and that NB was always in machine code.” - http://squoze.net/NB/README). >> >> - DMR also writes in that paper: "By 1971, our miniature computer center was beginning to have users. We all wanted to create interesting software more easily. Using assembler was dreary enough that B, despite its performance problems, had been supplemented by a small library of useful service routines and was being used for more and more new programs. Among the more notable results of this period was Steve Johnson’s first version of the yacc parser-generator” So, Yacc first appears in 1971 and is written in B. As such, it ran on both the PDP-11 and the GE/Honeywell. >> >> - It is a guess, but I would hypothesize that the c0/c1 structure of the early 1972/1973 C compilers goes all the way back to the GE/Honeywell implementation of B. In this respect it is suggestive that the “last1120” C compiler names its passes "nc0" and “nc1”, following shortly on the transitional “new B” / “nb”. If true, it would stand to reason to assume that this mainframe B compiler also used a similar recursive descent / operator precedence parsing scheme. >> >> - The DMR history paper then goes on to say that Johnson had a sabbatical at the University of Waterloo in 1972, but I think this might be a slip of the pen. A Uni of Waterloo retrospective says that he arrived late in 1972 (“In August 1972, […] a new arrival was causing a stir in the Math & Computer building at University of Waterloo – a brand new Honeywell 6050 mainframe size computer. […] Shortly after the arrival of the Honeywell, Steve Johnson came to the Math Faculty on sabbatical from Bell Labs.”). He brought B and Yacc with him ("I suspect that few people realize his key role in introducing Bell Labs culture to University of Waterloo so early, including B Programming Language, getchar(), putchar(), the beginnings of the notion of software portability and, of course, yacc.”). https://randalljhoward.com/tag/dead-whale/ The year 1973 is also supported by a resume from 1982 ("I spent a 9-month Sabbatical in 1973 at the University of Waterloo, where I taught courses in Advanced Applications Techniques and Algebraic Manipulation.” — https://stacks.stanford.edu/file/druid:ws821cy1376/ws821cy1376.pdf). 1973 is also a better match with the internship of Alan Snyder in that year. >> >> - In an interview Johnson mentions "When YACC first ran, it was very slow […] I set out to improve the size and space characteristics. Over the next several years, I rewrote the program over a dozen times, speeding it up by a factor of 10,000 or so. Many of my speedups involved proving theorems that we could cut this or that corner and still have a valid parser. The introduction of precedence was one example of this.” (https://www.computerworld.com/article/1570304/yacc-unix-and-advice-from-bell-labs-alumni-stephen-johnson.html). I suspect that a fair bit of this improvement happened in 1972, because he continues with "Dennis was actively working on B while I was writing YACC. One day, I came in and YACC would not compile – it was out of space. It turns out that I had been using every single slot in the symbol table. The night before, Dennis had added the ‘for’ statement to B, and the word ‘for’ took a slot, so YACC no longer fit!”. This suggests 1972 much more than 1974 as the timeframe he had in mind when saying this. >> >> - This also tallies with DMR’s account, writing: "When Steve Johnson visited the University of Waterloo on sabbatical in 1972, he brought B with him. It became popular on the Honeywell machines there, and later spawned Eh and Zed (the Canadian answers to ‘what follows B?’). When Johnson returned to Bell Labs in 1973, he was disconcerted to find that the language whose seeds he brought to Canada had evolved back home; even his own yacc program had been rewritten in C, by Alan Snyder.”. As explained above, I think this should be read as “late 1972” and “late 1973”. So: a first, early C version of Yacc can be placed at mid 1973. >> >> - Alan Snyder did the Honeywell version of his portable compiler in 1973 (the PDP-10 version and his thesis are from 1975) (https://retrocomputingforum.com/t/some-materials-on-early-c-and-the-history-of-c/3016/2). This compiler used yacc, which implies that by (late) 1973 yacc must have been stable, fast and compact enough to handle a sizable grammar. I can understand converting it to nascent C, as I have recently found yacc to be a great compiler test input. In the timeline, this Snyder version is close to the binary on the 4th edition tape. >> >> - B evolved at Waterloo. Report CS-75-23 from September 1975 says "Current efforts center on the language ‘B' which is already implemented on the HIS 6050 and PDP 11; we hope to have a version of B for the Microdata before January, 1976. […] The problem is now reduced to that of recoding the B compiler code generation section and the basic I/O primitives.” And report CS-75-29 from November of that year says "The B compiler is well suited for our preliminary experimentation with portability because it is nicely structured and therefore easily modified to generate code for other machines. This is largely due to the fact that it is a syntax directed compiler for a language which has a simple and compact syntax. The one-pass compiler is implemented in B.” I assume “syntax directed” in this context to mean that the Honeywell B compiler was recoded to use Yacc for its parser - - somewhere between 1973 and 1975. If so, that effort probably used the B version of Yacc that Johnson brought in 1973. The 1976 Eh and the 1978 Zed compilers for sure use Yacc to build their parser. >> >> - All this makes the Yacc binary on the 4th edition tape interesting to me, as it gives a window on the state of Yacc late in 1973 when Johnson returned to Bell Labs. The binary appears truncated at the 16kb mark, but a first quick look at the strings suggests it is quite similar to the source code that is included with the surviving 6th edition Yacc source code. Similar, but not fully identical. This is in a context where the surviving 1975 Yacc source looks decidedly 1973 in style. For instance the yyparse function in file “parser.c” looks like a B function that has been minimally edited to make it early C - https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/yacc/lib/parser.c Another example is in y2.c, where in function “setup()” the “foutput" variable is set to -2 by default; I believe this to be a remnant from B on the Honeywell, where that means to output to the batch console. >> >> I wonder how much this 1975 yacc source has diverted from the 1973 Snyder B => C port; I presume not much. In fact, this version of Yacc proved quite easy to revert back to B (or Eh, actually): https://gitlab.com/pnru/Thoth/-/tree/master/user/yacc >> >> - An interesting sidetrack is the evolution of Johnson’s Yacc manual / paper. Several versions appear to exist, all a bit different. Later versions (1979 ?) have the “=“ sign before actions as an deprecated feature, but the 1975 source code still insists on the ‘=‘ sign. AAP appears to have the oldest version (1975?) of the document and this version still has the equals sign as mandatory in its text (http://squoze.net/UNIX/v6/files/doc/yacc.pdf). In 7th edition manual and code base the use of this ‘=‘ has become optional. I wonder when and why this change was made, the old syntax seems harmless. >> >> - The 6th edition Yacc has an optional optimizer pass, "/usr/yacc/yopti” which was optionally run after Yacc completed. As far as I can tell, the source for this optimiser is lost. I have found no materials explaining this optimizer pass. >> >> - Between 6th edition and 7th edition the code base changes substantially, presumably further compaction and speed-up. It grows from ~1700 to ~2200 lines. The optimizer pass is integrated into the base package, support for Ratfor is dropped, etc. The source also starts to look like ‘real C’. Alternatively, the yacc source in 6th edition might not reflect the latest internal Bell version and actual yacc development was perhaps more gradual. Although I use the 7th edition version in my C recreation of the Eh compiler, it does not seem like it is a good base to approximate what the Uni of Waterloo might have used in 1975-1977. >> >> Now for the questions: >> >> - Do the above timeline and assumptions sound correct (or at least plausible) to those who were there? >> >> - Does anybody know of Yacc source code older that what is included in 6th edition (other than attempting to reverse engineer the recently recovered 4th edition binary)? >> >> - Does anybody know more about the missing Yacc optimizer in 6th edition, what it did, etc.? Or is the only way to compare and contrast with 7th edition where the (that?) optimizer is integrated? >> >> >> >> > > From tuhs at tuhs.org Thu Jan 8 04:52:50 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Wed, 7 Jan 2026 13:52:50 -0500 Subject: [TUHS] pic macros Message-ID: I haven't found pic in the TUHS v7 source tree. Does anyone have a running version of it? My reason for asking is that there is no detailed spec for pic's macro facility. I've found some surprises in the Gnu implementation and wonder whether they are inherited from the original. Thanks, Doug From tuhs at tuhs.org Thu Jan 8 05:04:30 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 07 Jan 2026 19:04:30 +0000 Subject: [TUHS] pic macros In-Reply-To: References: Message-ID: On Wednesday, January 7th, 2026 at 10:53, Douglas McIlroy via TUHS wrote: > I haven't found pic in the TUHS v7 source tree. Does anyone have a > running version of it? > > My reason for asking is that there is no detailed spec for pic's macro > facility. I've found some surprises in the Gnu implementation and > wonder whether they are inherited from the original. > > Thanks, > Doug There is one in the V8 source tree: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/pic This version has a changelog from 1980 to 1985 as well. - Matt G. From tuhs at tuhs.org Thu Jan 8 05:34:39 2026 From: tuhs at tuhs.org (Marc Haber via TUHS) Date: Wed, 7 Jan 2026 20:34:39 +0100 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow Message-ID: Hi, pardon me for jumping into this mailinglist that is so full of famous and knowledgeable people. I am the maintainer of adduser in Debian and am trying to make as much sense as possible in modern Unixoid systems. I am wondering about the difference between ! and * in the password field of /etc/shadow and before its invention in /etc/passwd. I think that until some ten years ago, there was still a difference between both, with one of the versions preventing login via password (but keeping it possible to use, for example, an ssh key to log in) and the other also making it impossible to use an ssh key to log in. I think that one also prevented su'ing to that account. This has been given up at least in GNU/Linux system a while ago with ! and * being kind of synonymous. It is common to put ! in front of a password hash to temporary lock an account while being able to restore the old password when the account is being unlocked. In Debian, the accounts that we deliver in a basic installation have "*" for a password, while useradd (from the shadow suite by Julianne Frances Haugh and Serge Hallyn, nowadays maintained on github) puts a ! in the password field when one does not set a password for a newly created account. Reading historic documents suggestst that ! used to be a notion for "temporarily locked" while * is the notation for "this account never had a password since it was created". The mixture of * and ! in the /etc/shadow field in Debian systems is kind of bothering my inner Adrian Monk, and I would like to either suggest that we (Debian) change to ! for the accounts in our default /etc/passwd or pester src:shadow to use * for newly created accounts. That being said, I'd like to solicit your opinion and historical knowledge about what ! and * in password fields were really meant to say in the beginning. Thank you very much. It is an honor to be allowed on thie Maiing List. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 From tuhs at tuhs.org Thu Jan 8 05:40:11 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Wed, 07 Jan 2026 19:40:11 +0000 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: Back when the (encrypted) passwords were in /etc/password, a * was a common way to make accounts that could not be logged into. This goes back forwever (putting a blank password field in just meant there was no password required to log in). This predated /etc/shaddow and even the inclusion of the “salt” characters at the beginning of the passwords. The ! to disable wasn’t something I saw. It must have come later (but before people started using programs to manipulate these things). From tuhs at tuhs.org Thu Jan 8 06:19:13 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 7 Jan 2026 15:19:13 -0500 Subject: [TUHS] pic macros In-Reply-To: References: Message-ID: below On Wed, Jan 7, 2026 at 1:53 PM Douglas McIlroy via TUHS wrote: > I haven't found pic in the TUHS v7 source tree. Does anyone have a > running version of it? > That's because it was not released in V7. pic left the labs as an unbundled component/tool, like the Korn shell, asd, mk, nawk, and nmake (ditroff was part of the later "toolchest" ditroff distributions; it might have been part of the original ditroff for the v6/v7 release that included the new C compiler). IIRC, the toolchest version was enhanced. That said, the entire ditroff system was part of V8, and pic can be found in /usr/src/cmd/pic. I think that should be close to what was in the toolchest version. > > My reason for asking is that there is no detailed spec for pic's macro > facility. I've found some surprises in the Gnu implementation and > wonder whether they are inherited from the original. > > Thanks, > Doug > From tuhs at tuhs.org Thu Jan 8 07:13:39 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 07 Jan 2026 21:13:39 +0000 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: On Wednesday, January 7th, 2026 at 11:40, Ron Natalie via TUHS wrote: > Back when the (encrypted) passwords were in /etc/password, a * was a > common way to make accounts that could not be logged into. This goes > back forwever (putting a blank password field in just meant there was no > password required to log in). This predated /etc/shaddow and even the > inclusion of the “salt” characters at the beginning of the passwords. > The ! to disable wasn’t something I saw. It must have come later (but > before people started using programs to manipulate these things). The passwd(5) (or 4 for USG stream) manpage should give some pointers. As of the initial System V release (pre shadow), the only defined behaviors of this field are either an encrypted (via crypt(3)) string or an empty (null) string for no password. Additionally, a password can be followed by a comma and then aging information. I don't see any explicit handling of * or !. Presumably using * just means that the expected output of crypt(3) is *, an unlikely if not impossible scenario, leading to the behavior of no login available. I'll have to check the passwd(4) page in my SVR4 manuals at home. In any case, that's where I'd suggest looking. If it's not in the manuals, it may qualify as unintended behavior or something like that, meaning even if there is any handling for these characters specially (which I couldn't find in login(1), su(1), or any of the libc passwd stuff), that handling was never publicized. - Matt G. From tuhs at tuhs.org Thu Jan 8 07:26:08 2026 From: tuhs at tuhs.org (Hauke Fath via TUHS) Date: Wed, 7 Jan 2026 22:26:08 +0100 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: <20260107222608801386.c931b407@Espresso.Rhein-Neckar.DE> On Wed, 7 Jan 2026 20:34:39 +0100, Marc Haber via TUHS wrote: > Reading historic documents suggestst that ! used to be a notion for > "temporarily locked" while * is the notation for "this account never > had a password since it was created". A while back, I looked into how various OSes set up shadow passwords, in a vain attempt to run YP with shadow passwords. AFAIR, neither the 4.4BSD derived OSes (NetBSD, FreeBSD), nor Solarish (Solaris*, OmniOS) use an exclamation mark in the shadow file's password field. > The mixture of * and ! in the /etc/shadow field in Debian systems is > kind of bothering my inner Adrian Monk, and I would like to either > suggest that we (Debian) change to ! for the accounts in our default > /etc/passwd or pester src:shadow to use * for newly created accounts. Given that Linuxen put an 'x' into the /etc/passwd password field, when all other OSes I looked at use a '*', I am inclined to see the '!' as a Linuxism. Cheerio, Hauke * -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany From tuhs at tuhs.org Thu Jan 8 07:34:59 2026 From: tuhs at tuhs.org (Peter Yardley via TUHS) Date: Thu, 8 Jan 2026 08:34:59 +1100 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: <0AC42BE9-9F3F-4953-BD14-9CA401890031@gmail.com> Hi, I found this on the interweb and it corresponds to my memories from my sysadmin days... "If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means)." > On 8 Jan 2026, at 8:13 am, segaloco via TUHS wrote: > > On Wednesday, January 7th, 2026 at 11:40, Ron Natalie via TUHS wrote: > >> Back when the (encrypted) passwords were in /etc/password, a * was a >> common way to make accounts that could not be logged into. This goes >> back forwever (putting a blank password field in just meant there was no >> password required to log in). This predated /etc/shaddow and even the >> inclusion of the “salt” characters at the beginning of the passwords. >> The ! to disable wasn’t something I saw. It must have come later (but >> before people started using programs to manipulate these things). > > The passwd(5) (or 4 for USG stream) manpage should give some pointers. > As of the initial System V release (pre shadow), the only defined > behaviors of this field are either an encrypted (via crypt(3)) string > or an empty (null) string for no password. Additionally, a password can > be followed by a comma and then aging information. I don't see any > explicit handling of * or !. Presumably using * just means that the > expected output of crypt(3) is *, an unlikely if not impossible > scenario, leading to the behavior of no login available. > > I'll have to check the passwd(4) page in my SVR4 manuals at home. In > any case, that's where I'd suggest looking. If it's not in the manuals, > it may qualify as unintended behavior or something like that, meaning > even if there is any handling for these characters specially (which I > couldn't find in login(1), su(1), or any of the libc passwd stuff), that > handling was never publicized. > > - Matt G. .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From tuhs at tuhs.org Thu Jan 8 07:43:32 2026 From: tuhs at tuhs.org (Erik E. Fair via TUHS) Date: Wed, 07 Jan 2026 13:43:32 -0800 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: <18807.1767822212@cesium.clock.org> Fundamentally, the question is whether the cryptographic hash of an input password can produce "*" or "!" or any other arbitrary string you put in the password field of /etc/passwd, /etc/master.passwd, etc., for matching & thus authentication. If it cannot without regard to any input string given to login(1) and subsequently hashed, then the account is disabled - no special casing required. No match, no login. Anything else (like password comparison being bypassed if the /etc/passwd string is null) is going to be an explicit exception case found in login(1)'s source code or anything else that processes passwords for authentication (e.g., ftpd(8), pppd(8)). Any string used for disabling accounts (other than traditional "*") could be processed by other (e.g., account management) software for its own purposes, so long as those strings cannot be produced by handing some other string to login(1) and hashed using the standard methods to produce an unwanted match (and thus unwanted successful authentication). Erik From tuhs at tuhs.org Thu Jan 8 07:50:39 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 08 Jan 2026 07:50:39 +1000 Subject: [TUHS] pic macros In-Reply-To: <20260107211438.pkzopkmtfruejp34@illithid> References: <20260107211438.pkzopkmtfruejp34@illithid> Message-ID: -------- Original Message -------- From: "G. Branden Robinson" Sent: 8 January 2026 7:14:38 am AEST To: tuhs at tuhs.org Cc: wkt at tuhs.org Subject: Re: [TUHS] Re: pic macros [CCing Warren so he can forward if necessary; as far as I know the Gmail->TUHS relationship is still sour, at least for me] At 2026-01-07T15:19:13-0500, Clem Cole via TUHS wrote: > On Wed, Jan 7, 2026 at 1:53 PM Douglas McIlroy via TUHS > wrote: > > I haven't found pic in the TUHS v7 source tree. Does anyone have a > > running version of it? > > > That's because it was not released in V7. As someone who definitely Wasn't There but has done a little research, I'd venture that pic wasn't yet _finished_ in time for V7. CSTR #97, "A Typesetter-Independent TROFF", by Kernighan, documents the process of creating same. See §7, "Graphics Commands", where he introduces the `\D` troff escape sequence upon which pic relies as a translation target. Writing in 1982, Kernighan says: "Since actual output is done by a post-processor, not TROFF, new capabilities for graphics have been easy to add. TROFF now recognizes commands for drawing diagonal lines, circles, ellipses, circular arcs, and quadratic B-splines; these are used in the PIC[...] and IDEAL[...] languages." (p. 2; PS/PDF p. 4) > (ditroff was part of the later "toolchest" ditroff distributions; it > might have been part of the original ditroff for the v6/v7 release > that included the new C compiler) If I understand the history correctly, it would certainly have had to have been backported to those Unices; V7 is dated 1979, and Kernighan reports his work on what came to be known as "ditroff" in "early 1979" per CSTR #97. Regards, Branden -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From tuhs at tuhs.org Thu Jan 8 08:11:40 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Thu, 8 Jan 2026 08:11:40 +1000 Subject: [TUHS] pic macros In-Reply-To: References: <20260107211438.pkzopkmtfruejp34@illithid> Message-ID: We got the ditroff tape distinct from our 4.2bsd tape for Leeds uni, 1982-3 time frames. Somebody local did driver work for a versatec printer we had. Odd wet xerography style printing on continuous paper with cut marks printed in as it did pages. I think it was 200dpi or worse, I have a printout somewhere set on it in old English font. (The solvent evaporated as you walked up to get your printout) G On Thu, 8 Jan 2026, 7:50 am Warren Toomey via TUHS, wrote: > > > > -------- Original Message -------- > From: "G. Branden Robinson" > Sent: 8 January 2026 7:14:38 am AEST > To: tuhs at tuhs.org > Cc: wkt at tuhs.org > Subject: Re: [TUHS] Re: pic macros > > [CCing Warren so he can forward if necessary; as far as I know the > Gmail->TUHS relationship is still sour, at least for me] > > At 2026-01-07T15:19:13-0500, Clem Cole via TUHS wrote: > > On Wed, Jan 7, 2026 at 1:53 PM Douglas McIlroy via TUHS > > wrote: > > > I haven't found pic in the TUHS v7 source tree. Does anyone have a > > > running version of it? > > > > > That's because it was not released in V7. > > As someone who definitely Wasn't There but has done a little research, > I'd venture that pic wasn't yet _finished_ in time for V7. > > CSTR #97, "A Typesetter-Independent TROFF", by Kernighan, documents the > process of creating same. See §7, "Graphics Commands", where he > introduces the `\D` troff escape sequence upon which pic relies as a > translation target. Writing in 1982, Kernighan says: > > "Since actual output is done by a post-processor, not TROFF, new > capabilities for graphics have been easy to add. TROFF now recognizes > commands for drawing diagonal lines, circles, ellipses, circular arcs, > and quadratic B-splines; these are used in the PIC[...] and IDEAL[...] > languages." (p. 2; PS/PDF p. 4) > > > (ditroff was part of the later "toolchest" ditroff distributions; it > > might have been part of the original ditroff for the v6/v7 release > > that included the new C compiler) > > If I understand the history correctly, it would certainly have had to > have been backported to those Unices; V7 is dated 1979, and Kernighan > reports his work on what came to be known as "ditroff" in "early 1979" > per CSTR #97. > > Regards, > Branden > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From tuhs at tuhs.org Thu Jan 8 08:31:58 2026 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Wed, 7 Jan 2026 14:31:58 -0800 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: <20260107222608801386.c931b407@Espresso.Rhein-Neckar.DE> References: <20260107222608801386.c931b407@Espresso.Rhein-Neckar.DE> Message-ID: <8747fd08-eff9-4d43-9f52-b31581e85ae5@oracle.com> On 1/7/26 13:26, Hauke Fath via TUHS wrote: > On Wed, 7 Jan 2026 20:34:39 +0100, Marc Haber via TUHS wrote: >> Reading historic documents suggestst that ! used to be a notion for >> "temporarily locked" while * is the notation for "this account never >> had a password since it was created". > > A while back, I looked into how various OSes set up shadow passwords, > in a vain attempt to run YP with shadow passwords. AFAIR, neither the > 4.4BSD derived OSes (NetBSD, FreeBSD), nor Solarish (Solaris*, OmniOS) > use an exclamation mark in the shadow file's password field. > > * The web hosted version of the man page is a little out of date now - the version shipped in the latest updates documents the following lock strings as options for the password field - but none have a ! in: *LK* The lock string is defined as *LK* in the first four (or only four) characters of the password field if the account was manually locked, by an ad- min running passwd -l. *AL* Prefix on the password hash when the account was automatically locked due to the number of authenti- cation failures reaching the configured maximum al- lowed. See policy.conf(5) and user_attr(5). NP Used to indicate an account is active but not par- ticipating in password authentication. It can run cron jobs and may be able to authenticate using a method other than a password hash stored in the nameservice, for example SSH publickey or with Ker- beros. Exempt from automatic lock out due to failed pass- word authentication attempts. Useful for system/ap- pliication accounts and Roles when roleauth=user is set in user_attr(5). The NP value can be set by passwd -N or delivered as the value in a pkg(7) user action. UP Set by useradd(8) when the account is initially created, and has yet to have a password set. Users in the UP state can not authenticate to the system. When an account is delivered via a pkg(7) action UP should be used if the user is intended to have a password assigned later using passwd(1). -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From tuhs at tuhs.org Thu Jan 8 08:43:33 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Wed, 07 Jan 2026 22:43:33 +0000 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: I was going way back before System V. We moved our passwords out of public view in /etc/passwd back in our version 6 variants. Yes, * worked fine because it could never match the encrypted password. The V6 manual doesn’t mention this “hack.” It still talks about GCOS (which is where most people had started putting information like the user’s real name. Amusingly at BRL, we put the user name in an email-complaint format such as: ron::58:33:Ron Natalie :/sys1/ron: This bit one of our admins once. He wanted to find his entry in the file and typed: grep /etc/passwd Alas, he was root at the time. ------ Original Message ------ >From "segaloco via TUHS" To "The Eunuchs Hysterical Society" Date 1/7/2026 4:13:39 PM Subject [TUHS] Re: Questions about * and ! in the password field of passwd and shadow >On Wednesday, January 7th, 2026 at 11:40, Ron Natalie via TUHS wrote: > >> Back when the (encrypted) passwords were in /etc/password, a * was a >> common way to make accounts that could not be logged into. This goes >> back forwever (putting a blank password field in just meant there was no >> password required to log in). This predated /etc/shaddow and even the >> inclusion of the “salt” characters at the beginning of the passwords. >> The ! to disable wasn’t something I saw. It must have come later (but >> before people started using programs to manipulate these things). > >The passwd(5) (or 4 for USG stream) manpage should give some pointers. >As of the initial System V release (pre shadow), the only defined >behaviors of this field are either an encrypted (via crypt(3)) string >or an empty (null) string for no password. Additionally, a password can >be followed by a comma and then aging information. I don't see any >explicit handling of * or !. Presumably using * just means that the >expected output of crypt(3) is *, an unlikely if not impossible >scenario, leading to the behavior of no login available. > >I'll have to check the passwd(4) page in my SVR4 manuals at home. In >any case, that's where I'd suggest looking. If it's not in the manuals, >it may qualify as unintended behavior or something like that, meaning >even if there is any handling for these characters specially (which I >couldn't find in login(1), su(1), or any of the libc passwd stuff), that >handling was never publicized. > >- Matt G. From tuhs at tuhs.org Thu Jan 8 11:09:20 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 08 Jan 2026 01:09:20 +0000 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: On Wednesday, January 7th, 2026 at 14:43, Ron Natalie via TUHS wrote: > > This bit one of our admins once. He wanted to find his entry in the > file and typed: > > grep /etc/passwd > My next door neighbors could probably hear how loud of a "oh nooooooo" I said reading that.... So SVR4 says: > The password field consists of the character x. This field remains only for > compatibility reasons. Password information is contained in the file > /etc/shadow; see shadow(4). Then in shadow(4) the password field is so described: > A 13-character encrypted password for the user, > a lock string to indicate that the login is not accessible, > or no string to show that there is no password for the login. These lock strings are then things as described earlier in the thread like "*LK*" in the password field to indicate a lock. Unfortunately I'm not quickly finding a list of known lock strings in the documentation, they can probably be found in the sources of the passwd(1) command if nothing else. I also checked the 4.4BSD and Research V10 manuals, neither indicate anything other than an encrypted string or null can be used, the latter resulting in a password-less login. No mention of special meaning in other characters. I suspect if there ever was any difference between * and ! as representations of a special case, those may not have been all that widespread. So all in all, the password field has formally accumulated the following features from what I can tell: - encrypted string - null (no password) - comma plus aging info (USG stream) - x (for shadow, later USG) - *..* (later USG, .. includes "LK" for locked) The consensus here thus far is that * (or !) were simply taking advantage of the fact that neither would be valid crypt(3) output so no user password should compare true. I haven't come across any historic documentation describing these as having any special meaning otherwise. - Matt G. From tuhs at tuhs.org Thu Jan 8 11:24:13 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Wed, 7 Jan 2026 17:24:13 -0800 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> Message-ID: <04b00f4d-d082-49af-a1ed-6c1730cd0b00@mhorton.net> I had some extra time today, so I went ahead and scanned the Cherry card and the Bolsky card. The Cherry card is unique in that the pages aren't all the same length. Each section has slightly longer pages, with a "tab" heading at the bottom of the first page of each section. See the 3rd page of the PDF for the full effect. https://stargatemuseum.org/maps/UNIX_Reference_Card_Second_Edition_by_L.L.Cherry.pdf https://stargatemuseum.org/maps/UNIX_System_Quick_Guide.pdf Thanks, /Mary Ann Horton/ (she/her/ma'am)       Award Winning Author maryannhorton.com On 1/6/26 17:41, Clem Cole via TUHS wrote: > Agreed I’ll try to push doing some scans up onto the TUHS archived a big > farther up my ToDo list. > > Sent from a handheld expect more typos than usual > > > On Tue, Jan 6, 2026 at 7:36 PM Jonathan Gray via TUHS wrote: > >> Thanks, I hadn't considered blank pages. Of the missing pages in the scan >> (4, 6, 18) only page 6 (chgrp to du) is listed in the contents. >> >> The reference card is not often discussed, but as far as I can tell there >> was >> only one edition in 1979. So it seems likely you have the same one as >> Clem. >> >> On Sun, Jan 04, 2026 at 12:07:07PM -0800, Mary Ann Horton via TUHS wrote: >>> I also have a copy of Cherry's booklet (spiral bound, 1979) in my >>> collection. >>> >>> Comparing it with the incompete chilton scan, it's only missing pages 4 >> and >>> 22. The other missing pages are blank. >>> >>> I gather this is the same one Clem has? If not, let me know and I'll scan >>> it. >>> >>> Thanks, >>> >>> /Mary Ann Horton/ (she/her/ma'am) >>> Award Winning Author >>> maryannhorton.com >>> >>> >>> >>> On 1/3/26 20:41, Jonathan Gray via TUHS wrote: >>>> On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: >>>>> Also, while looking for the vi cards, I turned up two wonderful >> artifacts >>>>> that I'll try to get scanned and added to TUHS at some point. When >> you >>>>> purchased V7 from AT&T, you got one copy of the printed docs and a >> small >>>>> "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry >>>>> compiled. Also, when DEC released V7M-11, they printed a small >> flip-binding >>>>> 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is >>>>> similar but different. >>>> Was the first edition also distributed to V6 licensees? >>>> >>>> -- >>>> >>>> UNIX Reference Card - First Edition >>>> L. L. Cherry >>>> September, 1975 >>>> A handy guide to UNIX commands and syntax. >>>> >>>> mentioned in: >>>> tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 >>>> v10/doc/bibliog.a unpm-docs >>>> >>>> -- >>>> >>>> UNIX Reference Card >>>> distributed by >>>> Computing Information Service >>>> BELL LABORATORIES >>>> Murray Hill, N. J. 07974 >>>> compiled by Lorinda Cherry >>>> Second Edition, March 1979 >>>> >>>> incomplete scan, some pages missing: >>>> http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf >>>> viahttp:// >> www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm >>>> CHM has a copy, not currently scanned >>>> https://www.computerhistory.org/collections/catalog/102632799/ >>>> >>>> spiral bound >>>> https://www.flickr.com/photos/n1kdo/53136436051 >>>> comb bound >>>> >> https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 >> From tuhs at tuhs.org Thu Jan 8 21:32:16 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Thu, 8 Jan 2026 12:32:16 +0100 Subject: [TUHS] Photo of old Unix manuals In-Reply-To: References: Message-ID: Oh, this is really good. I do wonder if the old manuals match the scans or t?roff files we have! having scans of those would be neat. aap On 06/01/26, Douglas McIlroy via TUHS wrote: > Sorry, I thought the referenced attachment would be replaced > by a link to a saved copy as happens with some attachments, > but it turns out to exceed the tuhs size limit. it's now at > https://www.cs.dartmouth.edu/~doug/UnixManuals.jpg. > In case anyone is wondering, the only printed form of v10 was > the trade binding. Only v6, v7 (non-trade), and v10 included > extra volumes of companion documents. > > Doug. > > Date: Wed, 31 Dec 2025 10:54:43 -0500 > From: Douglas McIlroy > Subject: [TUHS] Re: Photo of old Unix manuals > To: TUHS main list > > Attached is a photo of all the Research manuals. > Top row v1-v5 (note the original owner's name on v1 and v2) > Middle row v6 (2 vols), v7 (3 vols) > Bottom row v7 (trade binding), v8, v9, v10 (2 vols, trade binding) From tuhs at tuhs.org Thu Jan 8 23:25:02 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Thu, 08 Jan 2026 06:25:02 -0700 Subject: [TUHS] 3 minute clip from Al Aho about awk's original development Message-ID: <202601081325.608DP2jC096157@freefriends.org> https://www.youtube.com/watch?v=5Zsk5L225Zs From tuhs at tuhs.org Fri Jan 9 07:21:22 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Fri, 9 Jan 2026 07:21:22 +1000 Subject: [TUHS] Fwd: Amdahl UTS Source Code Message-ID: All, I received this e-mail from Andrew Gadsby: Hello Warren In the mid 1980s I was a Amdahl UTS sysadmin so I was amazed when I found the UTS system at https://www.tuhs.org/Archive/Distributions/IBM/370/ I booted it up and got it running, which was great fun. Anyway, as I explored this release I realised that it is complete and includes all of the utility and kernel source code -is also builds within the booted system. This was a complete surprise to me and bought back many memories of those early days. I have extracted the source code and am working on some notes on using this beast. Would you be interested in adding this material to the site? If so I’ll pull my notes and the code together over the next few days and send you a link so you can take a look. Andrew has some concerns about the copyright on the modifications. He adds: The more I look at this the more it looks like a V7 research Unix, as per your existing PDP11 source code but with modifications to make it run on the 370 - not complete as for example the sys/sched() code is empty so there’s no paging or swapping. Some of the documentation is by the original Unix team - e.g doc/out/iosys by Dennis Ritchie in 1981. I also think “Pugs” may have been doing something on it as well, as there’s an old mail entry for him from c. 1980. If he’s on your mailing list maybe he can give some input? I’ve still not found any copyright notices. Does any of this help with copyright concerns? I will get you a fuller set of files to you when I’ve figured out more about the kernel rebuild and disk formatting process. That’ll help me get a starter guide written - the included 3270 driver is a pain but I’m beating it into submission- who needs a backslash character anyway! I thnk Tom Lyons ("Pugs") is on the list, so if Tom and/or others could provide any insights that would be wonderful :-) Thanks, Warren From tuhs at tuhs.org Fri Jan 9 07:36:09 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Thu, 8 Jan 2026 13:36:09 -0800 Subject: [TUHS] Fwd: Amdahl UTS Source Code In-Reply-To: References: Message-ID: This has been "known" for a while. It's definitely the V7 port to Amdahl, known internally as "Au". There's no swapping or paging because the underlying VM system provided virtual memory. Being V7, there's no problem with the UNIX license, but Fujitsu owns the Amdahl IP now. I have a hard time believing anyone would care. I've toyed with it, but the folks who have done a lot more hang out on Discord: "Mainframe Enthusiasts" # uts-and-all-nixes: https://discord.com/channels/423767742546575361/871957791923920967 Sadly, I don't remember how to do the kernel build and disk formatting. I'm curious - how did you extract the source code? On Thu, Jan 8, 2026 at 1:21 PM Warren Toomey via TUHS wrote: > All, I received this e-mail from Andrew Gadsby: > > Hello Warren > > In the mid 1980s I was a Amdahl UTS sysadmin so I was amazed when I > found the UTS system at > https://www.tuhs.org/Archive/Distributions/IBM/370/ > > I booted it up and got it running, which was great fun. Anyway, as I > explored this release I realised that it is complete and includes all > of the utility and kernel source code -is also builds within the booted > system. This was a complete surprise to me and bought back many > memories of those early days. > > I have extracted the source code and am working on some notes on using > this beast. Would you be interested in adding this material to the > site? If so I’ll pull my notes and the code together over the next few > days and send you a link so you can take a look. > > Andrew has some concerns about the copyright on the modifications. He adds: > > The more I look at this the more it looks like a V7 research Unix, as > per your existing PDP11 source code but with modifications to make it > run on the 370 - not complete as for example the sys/sched() code is > empty so there’s no paging or swapping. Some of the documentation is > by the original Unix team - e.g doc/out/iosys by Dennis Ritchie in 1981. > > I also think “Pugs” may have been doing something on it as well, > as there’s an old mail entry for him from c. 1980. If he’s on your > mailing list maybe he can give some input? I’ve still not found > any copyright notices. > > Does any of this help with copyright concerns? > > I will get you a fuller set of files to you when I’ve figured out > more about the kernel rebuild and disk formatting process. That’ll > help me get a starter guide written - the included 3270 driver is > a pain but I’m beating it into submission- who needs a backslash > character anyway! > > I thnk Tom Lyons ("Pugs") is on the list, so if Tom and/or others could > provide any insights that would be wonderful :-) > > Thanks, Warren > From tuhs at tuhs.org Fri Jan 9 09:57:52 2026 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Thu, 8 Jan 2026 16:57:52 -0700 Subject: [TUHS] Fwd: Amdahl UTS Source Code In-Reply-To: References: Message-ID: I had no trouble installing it under VM/370. And, yeah, the video I saw from ... maybe Moshix? ... claimed it was v6 but playing with it, it's very much closer to v7. Dumping the source ought to be a pretty simple matter of mounting an emulated tape to hercules, dumping the files with tar, and then using the herc utils to extract them out again (or indeed, create a .tar file, dump THAT to awstape, extract the tar, and then use Unix tar to deal with the contents, which is actually probably easier than roundtripping the files through EBCDIC again). On Thu, Jan 8, 2026 at 2:36 PM Tom Lyon via TUHS wrote: > This has been "known" for a while. > > It's definitely the V7 port to Amdahl, known internally as "Au". > There's no swapping or paging because the underlying VM system provided > virtual memory. > Being V7, there's no problem with the UNIX license, but Fujitsu owns the > Amdahl IP now. I have a hard time believing anyone would care. > > I've toyed with it, but the folks who have done a lot more hang out on > Discord: > "Mainframe Enthusiasts" # uts-and-all-nixes: > https://discord.com/channels/423767742546575361/871957791923920967 > > Sadly, I don't remember how to do the kernel build and disk formatting. > I'm curious - how did you extract the source code? > > > > On Thu, Jan 8, 2026 at 1:21 PM Warren Toomey via TUHS > wrote: > > > All, I received this e-mail from Andrew Gadsby: > > > > Hello Warren > > > > In the mid 1980s I was a Amdahl UTS sysadmin so I was amazed when I > > found the UTS system at > > https://www.tuhs.org/Archive/Distributions/IBM/370/ > > > > I booted it up and got it running, which was great fun. Anyway, as I > > explored this release I realised that it is complete and includes all > > of the utility and kernel source code -is also builds within the > booted > > system. This was a complete surprise to me and bought back many > > memories of those early days. > > > > I have extracted the source code and am working on some notes on using > > this beast. Would you be interested in adding this material to the > > site? If so I’ll pull my notes and the code together over the next few > > days and send you a link so you can take a look. > > > > Andrew has some concerns about the copyright on the modifications. He > adds: > > > > The more I look at this the more it looks like a V7 research Unix, as > > per your existing PDP11 source code but with modifications to make it > > run on the 370 - not complete as for example the sys/sched() code is > > empty so there’s no paging or swapping. Some of the documentation is > > by the original Unix team - e.g doc/out/iosys by Dennis Ritchie in > 1981. > > > > I also think “Pugs” may have been doing something on it as well, > > as there’s an old mail entry for him from c. 1980. If he’s on your > > mailing list maybe he can give some input? I’ve still not found > > any copyright notices. > > > > Does any of this help with copyright concerns? > > > > I will get you a fuller set of files to you when I’ve figured out > > more about the kernel rebuild and disk formatting process. That’ll > > help me get a starter guide written - the included 3270 driver is > > a pain but I’m beating it into submission- who needs a backslash > > character anyway! > > > > I thnk Tom Lyons ("Pugs") is on the list, so if Tom and/or others could > > provide any insights that would be wonderful :-) > > > > Thanks, Warren > > > From tuhs at tuhs.org Fri Jan 9 16:59:19 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Thu, 8 Jan 2026 22:59:19 -0800 Subject: [TUHS] UNIX on Tandem Message-ID: Ran across this citation today. Anyone ever seen this paper? Known of the system? I'm pretty sure they're talking about Tandem(TM), not just generic tandem. A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl Electron Conf, 34 (October 1980), pp 16-8. From tuhs at tuhs.org Fri Jan 9 18:58:26 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Fri, 9 Jan 2026 19:58:26 +1100 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: <04b00f4d-d082-49af-a1ed-6c1730cd0b00@mhorton.net> References: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> <04b00f4d-d082-49af-a1ed-6c1730cd0b00@mhorton.net> Message-ID: Thank you. I see Warren has also added these to the archive. https://www.tuhs.org/Archive/Documentation/Cards/ On Wed, Jan 07, 2026 at 05:24:13PM -0800, Mary Ann Horton via TUHS wrote: > I had some extra time today, so I went ahead and scanned the Cherry card and > the Bolsky card. > > The Cherry card is unique in that the pages aren't all the same length. Each > section has slightly longer pages, with a "tab" heading at the bottom of the > first page of each section. See the 3rd page of the PDF for the full effect. > > https://stargatemuseum.org/maps/UNIX_Reference_Card_Second_Edition_by_L.L.Cherry.pdf > > https://stargatemuseum.org/maps/UNIX_System_Quick_Guide.pdf > > Thanks, > > /Mary Ann Horton/ (she/her/ma'am) >       Award Winning Author > maryannhorton.com > > > > On 1/6/26 17:41, Clem Cole via TUHS wrote: > > Agreed I’ll try to push doing some scans up onto the TUHS archived a big > > farther up my ToDo list. > > > > Sent from a handheld expect more typos than usual > > > > > > On Tue, Jan 6, 2026 at 7:36 PM Jonathan Gray via TUHS wrote: > > > > > Thanks, I hadn't considered blank pages. Of the missing pages in the scan > > > (4, 6, 18) only page 6 (chgrp to du) is listed in the contents. > > > > > > The reference card is not often discussed, but as far as I can tell there > > > was > > > only one edition in 1979. So it seems likely you have the same one as > > > Clem. > > > > > > On Sun, Jan 04, 2026 at 12:07:07PM -0800, Mary Ann Horton via TUHS wrote: > > > > I also have a copy of Cherry's booklet (spiral bound, 1979) in my > > > > collection. > > > > > > > > Comparing it with the incompete chilton scan, it's only missing pages 4 > > > and > > > > 22. The other missing pages are blank. > > > > > > > > I gather this is the same one Clem has? If not, let me know and I'll scan > > > > it. > > > > > > > > Thanks, > > > > > > > > /Mary Ann Horton/ (she/her/ma'am) > > > > Award Winning Author > > > > maryannhorton.com > > > > > > > > > > > > > > > > On 1/3/26 20:41, Jonathan Gray via TUHS wrote: > > > > > On Tue, Jun 04, 2024 at 10:32:25AM -0400, Clem Cole wrote: > > > > > > Also, while looking for the vi cards, I turned up two wonderful > > > artifacts > > > > > > that I'll try to get scanned and added to TUHS at some point. When > > > you > > > > > > purchased V7 from AT&T, you got one copy of the printed docs and a > > > small > > > > > > "purple/red" 9"x3.5" flip-binding reference card that Lorinda Cherry > > > > > > compiled. Also, when DEC released V7M-11, they printed a small > > > flip-binding > > > > > > 8"x4" reference called the "programmers guide" [AA-X7978-1C]—which is > > > > > > similar but different. > > > > > Was the first edition also distributed to V6 licensees? > > > > > > > > > > -- > > > > > > > > > > UNIX Reference Card - First Edition > > > > > L. L. Cherry > > > > > September, 1975 > > > > > A handy guide to UNIX commands and syntax. > > > > > > > > > > mentioned in: > > > > > tuhs Distributions/Research/Dan_Cross_v10/v10src.tar.bz2 > > > > > v10/doc/bibliog.a unpm-docs > > > > > > > > > > -- > > > > > > > > > > UNIX Reference Card > > > > > distributed by > > > > > Computing Information Service > > > > > BELL LABORATORIES > > > > > Murray Hill, N. J. 07974 > > > > > compiled by Lorinda Cherry > > > > > Second Edition, March 1979 > > > > > > > > > > incomplete scan, some pages missing: > > > > > http://www.chilton-computing.org.uk/inf/pdfs/idus/idus00.pdf > > > > > viahttp:// > > > www.chilton-computing.org.uk/inf/literature/notes/unix_notes_1_19.htm > > > > > CHM has a copy, not currently scanned > > > > > https://www.computerhistory.org/collections/catalog/102632799/ > > > > > > > > > > spiral bound > > > > > https://www.flickr.com/photos/n1kdo/53136436051 > > > > > comb bound > > > > > > > > https://www.worthpoint.com/worthopedia/bell-laboratories-unix-memorabilia-3759802979 > > > From tuhs at tuhs.org Fri Jan 9 19:06:48 2026 From: tuhs at tuhs.org (Marc Haber via TUHS) Date: Fri, 9 Jan 2026 10:06:48 +0100 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: Hello Everybody, On Wed, Jan 07, 2026 at 08:34:39PM +0100, Marc Haber wrote: >I am wondering about the difference between ! and * in the password >field of /etc/shadow and before its invention in /etc/passwd. I think >that until some ten years ago, there was still a difference between >both, with one of the versions preventing login via password (but >keeping it possible to use, for example, an ssh key to log in) and the >other also making it impossible to use an ssh key to log in. I think >that one also prevented su'ing to that account. Thank you for this fruitful discussion that has taught me that this has never been formally specified, and that the different flavours of Unixoid operating systems are doing their own thing in their /etc/passwd. Short research also told me that the format of /etc/passwd or other backing stores for the user account database are nowadays neither part of POSIX nor of SuS. I have learned something. Your answers are appreciated. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 From tuhs at tuhs.org Fri Jan 9 20:07:58 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Fri, 9 Jan 2026 21:07:58 +1100 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: On Thu, Jan 08, 2026 at 10:59:19PM -0800, Tom Lyon via TUHS wrote: > Ran across this citation today. Anyone ever seen this paper? Known of the > system? I'm pretty sure they're talking about Tandem(TM), not just > generic tandem. > > A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl > Electron Conf, 34 (October 1980), pp 16-8. Didn't find the paper, but did find: "The UNIX operating system environment has found wide use in a variety of time sharing, word processing, and data processing applications. Until recently, it was only available on single processor computer systems but now has been successfully emulated by D. L. Bayer and A. M. Usas on a nonstop multiprocessor computer system built by the Tandem Computer Company" G. Bergland, "An Experimental Telecommunications Test Bed" IEEE Journal on Selected Areas in Communications, vol. 1, no. 2, pp 322-326 February 1983, doi: 10.1109/JSAC.1983.1145923 https://ieeexplore.ieee.org/document/1145923 https://ptacts.uspto.gov/ptacts/public-informations/petitions/1466094/download-documents?artifactId=rWIj0W0HCvPrieJC6vvVEuPvLJcNtW8P3UfHNTXqn4Kq5QZxf_KBc44 more papers mentioned in BSTJ: C on the Tandem 16. A. M. Usas, Proc Tandem Users Group Convention, San Diego, California, September 15-17, 1980 A Model for a Tandem Software Development System. A. M. Usas, Proc Tandem Users Group Convention, San Diego, California, September 15-17, 1980. from 'Bell Laboratories Talks and Papers, 1979', snippets on Google Books: Bayer DL, The Tandem 16 Computer System and the Tandem/Unix Project Usas AM, Emulation of Unix on a Tandem 16 https://cs.brown.edu/people/faculty/ausas/ mentions Alan worked at Tandem after Bell Labs "the list of versions of the Portable C Compiler (as of April 1979) includes: Data General Nova Honeywell 6000 IBM System /360 and /370 Intel 8086 Interdata 8/32 PDP11 Tandem 16 VAX11/780" from tuhs Documentation/Papers/lions_PCCpass2_jun1979.pdf From tuhs at tuhs.org Fri Jan 9 21:17:17 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 09 Jan 2026 04:17:17 -0700 Subject: [TUHS] Questions about * and ! in the password field of passwd and shadow In-Reply-To: References: Message-ID: <202601091117.609BHH4s090682@freefriends.org> Marc Haber via TUHS wrote: > Short research also told me that the format of /etc/passwd > or other backing stores for the user account database are nowadays > neither part of POSIX nor of SuS. This is on purpose, IIUC. What is standardized is the C level routines getpwent() et al. This makes a lot of sense given that networked password and group databases have been around for a long time (Sun's NIS [nee YP], NIS+, and others.) Thus a local password file need not give the full story about all of the users who can login to a system. HTH, Arnold From tuhs at tuhs.org Fri Jan 9 21:56:31 2026 From: tuhs at tuhs.org (Brad Spencer via TUHS) Date: Fri, 09 Jan 2026 06:56:31 -0500 Subject: [TUHS] UNIX on Tandem In-Reply-To: (message from Tom Lyon via TUHS on Thu, 8 Jan 2026 22:59:19 -0800) Message-ID: Tom Lyon via TUHS writes: > Ran across this citation today. Anyone ever seen this paper? Known of the > system? I'm pretty sure they're talking about Tandem(TM), not just > generic tandem. > > A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl > Electron Conf, 34 (October 1980), pp 16-8. I don't know if my experiences with the Tandem are what is being talked about in that paper, but given its apparent date, I suspect I was after it, but here is what I remember about using a Tandem. Some version of the Tandem was white boxed at AT&T as the Starserver (or Star Server or some such) in the late 1990s time frame. I believe that it came to be used in the product I was on for possibly two reasons, the first was it might have been mandated from higher up and the second is that the RBOC customers wanted "fault tolerance" or at least some computer system that behaved a bit like some of the switching gear. The Tandem that was used was certainly FT in most ways. The backplane was an active beast where boards could be pulled out and replaced while the system was running and it would continue to run. Nearly every board type, from CPU, to memory to disk controllers to power supplies had at at least one spare and the load would be moved to a spare if the system detected a fault. All that you saw was a console message indicating that a board was removed or failed or whatever. The Unix that ran on it was a modified SVR3, I believe, and the processor was some sort of MIPS, if my memory is still correct. The group I was in had mostly the white boxed Starserver version which was a 120v / 240v sort of thing. But Tandem did make a central office version that ran on DC and we did have one of those because one of the RBOC customers wanted to put our system in a real central office which ran on DC mostly. The systems continued to be reliable until they got very old and the complicated backplane started to get quirks in it. The backplane was one component that really didn't have a fault tolerate part to it, or at least not enough of one and when the backplane got bad enough the system was pretty much done and over with. A lot of the software groups at 6200 Broad St. used the Starserver / Tandem for the products that they worked on in the same time frame. Later, the RBOC customers decided that FT wasn't worth the cost of the systems and we moved the product to HP with a brief diversion over to NCR (or GIS or whatever NCR was called after it was bought) for a bit. -- Brad Spencer - brad at anduin.eldar.org From tuhs at tuhs.org Fri Jan 9 23:58:35 2026 From: tuhs at tuhs.org (Arrigo Triulzi Lampugnani via TUHS) Date: Fri, 9 Jan 2026 14:58:35 +0100 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: On 9 Jan 2026, at 12:56, Brad Spencer via TUHS wrote: > > Tom Lyon via TUHS writes: > >> Ran across this citation today. Anyone ever seen this paper? Known of the >> system? I'm pretty sure they're talking about Tandem(TM), not just >> generic tandem. >> >> A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl >> Electron Conf, 34 (October 1980), pp 16-8. > Some version of the Tandem was white boxed at AT&T as the Starserver (or > Star Server or some such) in the late 1990s time frame. I believe that As a lapsed Tandem hand: in the late 90s it would have been an S-series which would indeed have been a MIPS processor. Before then Tandem had its own processor, the Cyclone, which survived into the K series of the mid-90s. It was a processor designed to work in lockstep, which is why they had modified MIPS w/o speculative execution for the S-series. In the ‘90s the “Unix” on NonStop Kernel (aka NSK) was USS, i.e. “Unix System Services”, which ran as a process over NSK and was used to run Java… I ported BIND to work under USS for my startup back then… I also destroyed the first iteration of the Parallel TCP/IP stack in their labs in Cupertino causing a huge testing Tandem to dump core to tape for a rather long time… oops. Arrigo From tuhs at tuhs.org Sat Jan 10 00:34:50 2026 From: tuhs at tuhs.org (Johan Helsingius via TUHS) Date: Fri, 9 Jan 2026 15:34:50 +0100 Subject: [TUHS] Fwd: Amdahl UTS Source Code In-Reply-To: References: Message-ID: <4f45816f-4737-49e9-a950-efa33b734e9c@Julf.com> On 08/01/2026 10:36 pm, Tom Lyon via TUHS wrote: > the folks who have done a lot more hang out on Discord The curse of the modern internet - total community fragmentation. I miss the days of listserv, USENET and (perhaps) IRC. Julf From tuhs at tuhs.org Sat Jan 10 02:31:40 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Fri, 9 Jan 2026 11:31:40 -0500 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: FWIW, I ported the Software Tools tape (in Ratfor) to Guardian, Tandem's original OS, in the late 70s using their Fortran compiler. I also wrote an implementation of pipes on top of Tandem's proprietary IPC, a shell called Quadpoint (because the prompt was "::"), and a Lisp interpreter. All three were written in Tandem Application Language, a derivative of HP SPL/3000 with C-ish senantics but a syntax closer to Pascal. Unfortunately, none of this escaped $EMPLOYER, so it is lost. On Fri, Jan 9, 2026, 8:58 AM Arrigo Triulzi Lampugnani via TUHS < tuhs at tuhs.org> wrote: > On 9 Jan 2026, at 12:56, Brad Spencer via TUHS wrote: > > > > Tom Lyon via TUHS writes: > > > >> Ran across this citation today. Anyone ever seen this paper? Known of > the > >> system? I'm pretty sure they're talking about Tandem(TM), not just > >> generic tandem. > >> > >> A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl > >> Electron Conf, 34 (October 1980), pp 16-8. > > Some version of the Tandem was white boxed at AT&T as the Starserver (or > > Star Server or some such) in the late 1990s time frame. I believe that > > As a lapsed Tandem hand: in the late 90s it would have been an S-series > which would indeed have been a MIPS processor. > > Before then Tandem had its own processor, the Cyclone, which survived into > the K series of the mid-90s. > > It was a processor designed to work in lockstep, which is why they had > modified MIPS w/o speculative execution for the S-series. > > In the ‘90s the “Unix” on NonStop Kernel (aka NSK) was USS, i.e. “Unix > System Services”, which ran as a process over NSK and was used to run Java… > > I ported BIND to work under USS for my startup back then… I also > destroyed the first iteration of the Parallel TCP/IP stack in their labs in > Cupertino causing a huge testing Tandem to dump core to tape for a rather > long time… oops. > > > Arrigo > > From tuhs at tuhs.org Sat Jan 10 02:40:40 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Fri, 9 Jan 2026 17:40:40 +0100 Subject: [TUHS] Updated installation instructions for v4 and v5, including B Message-ID: compiler Reply-To: Hi everyone, I have expanded my installation guide for UNIX v4 and wrote a similar one for v5 as well. While I was at it I also got my reconstructed B compiler running on both systems, there are instructions for that as well http://squoze.net/UNIX/v4/README http://squoze.net/UNIX/v5/README http://squoze.net/B/install Have fun, aap From tuhs at tuhs.org Sat Jan 10 02:57:44 2026 From: tuhs at tuhs.org (Michael Stiller via TUHS) Date: Fri, 9 Jan 2026 17:57:44 +0100 Subject: [TUHS] Updated installation instructions for v4 and v5, including B In-Reply-To: References: Message-ID: <3E80D069-E6AF-4B9D-9062-94DEE6AEF27B@me.com> Very cool Angelo. Kudos. Best regards, Michael > On 9. Jan 2026, at 17:40, Angelo Papenhoff via TUHS wrote: > > compiler > Reply-To: > > Hi everyone, > I have expanded my installation guide for UNIX v4 and wrote a similar one > for v5 as well. While I was at it I also got my reconstructed B compiler > running on both systems, there are instructions for that as well > > http://squoze.net/UNIX/v4/README > http://squoze.net/UNIX/v5/README > http://squoze.net/B/install > > Have fun, > aap From tuhs at tuhs.org Sat Jan 10 03:20:37 2026 From: tuhs at tuhs.org (andrew--- via TUHS) Date: Fri, 9 Jan 2026 09:20:37 -0800 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: <202601060751.6067pTMI079021@freefriends.org> References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> <202601060751.6067pTMI079021@freefriends.org> Message-ID: <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> the fio stuff has been reimplemented many times over. the marginal improvement it made was mostly in how the normal API was tweaked. what struck me in rereading the paper was a refererral to large files beng greater than 10MB. hahahahahaha > On Jan 5, 2026, at 11:51 PM, Arnold Robbins via TUHS wrote: > > Thalia Archibald via TUHS wrote: > >> On Jan 5, 2026, at 09:15, Dan Cross wrote: >>> Does anyone have a copy of the paper mentioned in the subject? >> >> >> Wiley has the authoritative online copy (accessible via Sci-Hub) >> https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380181105 >> and Erica Fischer uploaded a scan to the Internet Archive >> https://archive.org/details/tale-of-two-greps >> >> Thalia >> > > Thanks, that was an interesting read. > > Doug / Andrew -- is the fio library mentioned in the paper around > anywhere? Or did it evolve into Plan 9's Bio library? > > Thanks, > > Arnold From tuhs at tuhs.org Sat Jan 10 03:38:43 2026 From: tuhs at tuhs.org (Heinz Lycklama via TUHS) Date: Fri, 9 Jan 2026 09:38:43 -0800 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: <64e283d8-d093-4891-be23-366360a921ae@osta.com> I do remember that Doug Bayer and Alan Usas worked on the UNIX system on the Tandem computer system in the late 1970's at BTL after I had left BTL to join ISC in mid-1978, but I do not recall all the details of that system. Doug and I developed the MERT system at BTL in the mid 1970's. I also had occasion to re-acquaint with Alan during his time at Tandem in the mid 1990's where he had continued to develop UNIX software on the latest Tandem hardware and software at the time, and I was involved in various consulting projects for Tandem. Heinz On 1/9/2026 2:07 AM, Jonathan Gray via TUHS wrote: > On Thu, Jan 08, 2026 at 10:59:19PM -0800, Tom Lyon via TUHS wrote: >> Ran across this citation today. Anyone ever seen this paper? Known of the >> system? I'm pretty sure they're talking about Tandem(TM), not just >> generic tandem. >> >> A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl >> Electron Conf, 34 (October 1980), pp 16-8. > Didn't find the paper, but did find: > > "The UNIX operating system environment has found wide use in a variety > of time sharing, word processing, and data processing applications. > Until recently, it was only available on single processor computer > systems but now has been successfully emulated by D. L. Bayer and > A. M. Usas on a nonstop multiprocessor computer system built by the Tandem > Computer Company" > > G. Bergland, "An Experimental Telecommunications Test Bed" > IEEE Journal on Selected Areas in Communications, vol. 1, no. 2, pp 322-326 > February 1983, doi: 10.1109/JSAC.1983.1145923 > https://ieeexplore.ieee.org/document/1145923 > https://ptacts.uspto.gov/ptacts/public-informations/petitions/1466094/download-documents?artifactId=rWIj0W0HCvPrieJC6vvVEuPvLJcNtW8P3UfHNTXqn4Kq5QZxf_KBc44 > > more papers mentioned in BSTJ: > C on the Tandem 16. A. M. Usas, > Proc Tandem Users Group Convention, San Diego, California, > September 15-17, 1980 > > A Model for a Tandem Software Development System. A. M. Usas, > Proc Tandem Users Group Convention, San Diego, California, > September 15-17, 1980. > > from 'Bell Laboratories Talks and Papers, 1979', snippets on Google Books: > Bayer DL, The Tandem 16 Computer System and the Tandem/Unix Project > Usas AM, Emulation of Unix on a Tandem 16 > > https://cs.brown.edu/people/faculty/ausas/ > mentions Alan worked at Tandem after Bell Labs > > "the list of versions of the Portable C Compiler (as of April 1979) includes: > Data General Nova > Honeywell 6000 > IBM System /360 and /370 > Intel 8086 > Interdata 8/32 > PDP11 > Tandem 16 > VAX11/780" > from tuhs Documentation/Papers/lions_PCCpass2_jun1979.pdf From tuhs at tuhs.org Sat Jan 10 03:49:06 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Fri, 09 Jan 2026 17:49:06 +0000 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: Interesting. Having been around a bunch of odd-ball paralel systems (built a Purdue Dual-VAX, ported UNIX to the Denelcor HEP and designed its I/O system, worked wth 3B20s, etc) I always looked at other architectures. Tandem’s architecture was an interesting one, but I had not heard of a UNIX port to it. Had it’s own, unlike anything else, OS called TOS or something. Parallelism on the Tandem was really designed for reliability as opposed to outright multiplication of computer power (sort of like some of the Western stuff). It’s kind of the predecessor to some of the large scale cloud stuff today. I’d be interested in the paper if anybody can dig it up. ------ Original Message ------ >From "Tom Lyon via TUHS" To "TUHS main list" Date 1/9/2026 1:59:19 AM Subject [TUHS] UNIX on Tandem >Ran across this citation today. Anyone ever seen this paper? Known of the >system? I'm pretty sure they're talking about Tandem(TM), not just >generic tandem. > >A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl >Electron Conf, 34 (October 1980), pp 16-8. From tuhs at tuhs.org Sat Jan 10 03:52:00 2026 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Fri, 9 Jan 2026 09:52:00 -0800 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> <202601060751.6067pTMI079021@freefriends.org> <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> Message-ID: On 1/9/26 09:20, andrew--- via TUHS wrote: > what struck me in rereading the paper was a refererral to large files beng greater than 10MB. > hahahahahaha When we were going through all the programs in Solaris to port them to 64-bit as the first step in our Y2038-readiness, we decided that we could EOL the bfs command, as we no longer needed a special read only version of ed for which "Files can be up to 1024K bytes and 32K lines, with up to 512 characters, including new-line, per line (255 for 16-bit machines)." https://docs.oracle.com/cd/E86824_01/html/E54763/bfs-1.html We seem to have inherited it from SVR4, and I see a copy in the SVR3 source tree - I'm not sure how far back before that it was created. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From tuhs at tuhs.org Sat Jan 10 04:38:12 2026 From: tuhs at tuhs.org (Paul McJones via TUHS) Date: Fri, 9 Jan 2026 10:38:12 -0800 Subject: [TUHS] UNIX on Tandem In-Reply-To: <176798113141.1801233.6959025145068698178@minnie.tuhs.org> References: <176798113141.1801233.6959025145068698178@minnie.tuhs.org> Message-ID: <5E63A295-4430-4CCD-9EAA-F406B9418652@mcjones.org> > Tandem’s architecture was an interesting one, but I had > not heard of a UNIX port to it. Had it’s own, unlike anything else, OS > called TOS or something. The operating system was called GUARDIAN. The manuals are available here: https://bitsavers.org/pdf/tandem/ And this is an SOSP’81 paper about the design of the operating system: https://doi.org/10.1145/800216.806587 From tuhs at tuhs.org Sat Jan 10 04:39:58 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 09 Jan 2026 18:39:58 +0000 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> <202601060751.6067pTMI079021@freefriends.org> <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> Message-ID: On Friday, January 9th, 2026 at 09:52, Alan Coopersmith via TUHS wrote: > On 1/9/26 09:20, andrew--- via TUHS wrote: > > > what struck me in rereading the paper was a refererral to large files beng greater than 10MB. > > hahahahahaha > > > When we were going through all the programs in Solaris to port them to 64-bit > as the first step in our Y2038-readiness, we decided that we could EOL the > bfs command, as we no longer needed a special read only version of ed > for which "Files can be up to 1024K bytes and 32K lines, with up to > 512 characters, including new-line, per line (255 for 16-bit machines)." > > https://docs.oracle.com/cd/E86824_01/html/E54763/bfs-1.html > > We seem to have inherited it from SVR4, and I see a copy in the SVR3 source > tree - I'm not sure how far back before that it was created. > > -- > -Alan Coopersmith- alan.coopersmith at oracle.com > Oracle Solaris Engineering - https://blogs.oracle.com/solaris Earliest bfs(1) I can find is in PWB: https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/usr/man/man1/bfs.1 This cemented it in the PWB-to-commercial line from 1977 on. For the record, bfs(1) is not in USG PG-II or PG-III so is likely squarely from PWB. - Matt G. From tuhs at tuhs.org Sat Jan 10 04:42:16 2026 From: tuhs at tuhs.org (Charles H Sauer (he/him) via TUHS) Date: Fri, 9 Jan 2026 12:42:16 -0600 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: <483199ae-845b-44db-931d-34ad89c2ffed@technologists.com> On 1/9/2026 12:59 AM, Tom Lyon via TUHS wrote: > Ran across this citation today. Anyone ever seen this paper? Known of the > system? I'm pretty sure they're talking about Tandem(TM), not just > generic tandem. > > A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl > Electron Conf, 34 (October 1980), pp 16-8. Doug Jewett and other people instrumental in the early days of AIX went on to Tandem in Austin to create the Tandem S2 (MIPS-based) hardware and a fault-tolerant reworked version of SVR3 for that hardware. Doug suggests that Peter Norwood's paper at https://archive.org/details/tandemsr7-1/page/n11/mode/2up is likely the best introduction. Doug also suggests "This paper touches on some of the hardware and the software aspects of S2: D. Jewett, "Integrity S2: A Fault-Tolerant Unix Platform," Proc. 21st International Symposium Fault-Tolerant Computing, July 1991." However, I don't know of an accessible version of that reference. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From tuhs at tuhs.org Sat Jan 10 05:34:20 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Fri, 9 Jan 2026 14:34:20 -0500 Subject: [TUHS] A Tale of Two Greps (Andrew Hume) In-Reply-To: <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> References: <1867BE7A-69B0-451B-B6EF-F02FAB9F8164@archibald.dev> <202601060751.6067pTMI079021@freefriends.org> <77596BE8-804B-4082-826B-A58AC3B36148@humeweb.com> Message-ID: Is that 10MB per record, Andrew? :-) ===== mindthegapdialogs.com north-fork.info On Fri, Jan 9, 2026 at 12:20 PM andrew--- via TUHS wrote: > the fio stuff has been reimplemented many times over. > the marginal improvement it made was mostly in how the normal API was > tweaked. > > what struck me in rereading the paper was a refererral to large files beng > greater than 10MB. > hahahahahaha > > > > On Jan 5, 2026, at 11:51 PM, Arnold Robbins via TUHS > wrote: > > > > Thalia Archibald via TUHS wrote: > > > >> On Jan 5, 2026, at 09:15, Dan Cross wrote: > >>> Does anyone have a copy of the paper mentioned in the subject? > >> > >> > >> Wiley has the authoritative online copy (accessible via Sci-Hub) > >> https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380181105 > >> and Erica Fischer uploaded a scan to the Internet Archive > >> https://archive.org/details/tale-of-two-greps > >> > >> Thalia > >> > > > > Thanks, that was an interesting read. > > > > Doug / Andrew -- is the fio library mentioned in the paper around > > anywhere? Or did it evolve into Plan 9's Bio library? > > > > Thanks, > > > > Arnold > > From tuhs at tuhs.org Sat Jan 10 06:22:22 2026 From: tuhs at tuhs.org (Ronald Natalie via TUHS) Date: Fri, 09 Jan 2026 20:22:22 +0000 Subject: [TUHS] UNIX on Tandem In-Reply-To: <5E63A295-4430-4CCD-9EAA-F406B9418652@mcjones.org> References: <176798113141.1801233.6959025145068698178@minnie.tuhs.org> <5E63A295-4430-4CCD-9EAA-F406B9418652@mcjones.org> Message-ID: I guess T/TOS was the original name (Tandem / Transaction Operating System) but they tossed it for Guradian. ------ Original Message ------ From "Paul McJones" To "Ron Natalie" Cc tuhs at tuhs.org Date 1/9/2026 1:38:12 PM Subject Re: [TUHS] Re: UNIX on Tandem >>Tandem’s architecture was an interesting one, but I had >>not heard of a UNIX port to it. Had it’s own, unlike anything else, >>OS >>called TOS or something. > >The operating system was called GUARDIAN. The manuals are available >here: > >https://bitsavers.org/pdf/tandem/ > >And this is an SOSP’81 paper about the design of the operating system: > >https://doi.org/10.1145/800216.806587 From tuhs at tuhs.org Sat Jan 10 06:41:28 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 9 Jan 2026 13:41:28 -0700 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: <176798113141.1801233.6959025145068698178@minnie.tuhs.org> <5E63A295-4430-4CCD-9EAA-F406B9418652@mcjones.org> Message-ID: I thought it was NONSTOP at one point... Warner On Fri, Jan 9, 2026 at 1:22 PM Ronald Natalie via TUHS wrote: > I guess T/TOS was the original name (Tandem / Transaction Operating > System) but they tossed it for Guradian. > > > ------ Original Message ------ > From "Paul McJones" > To "Ron Natalie" > Cc tuhs at tuhs.org > Date 1/9/2026 1:38:12 PM > Subject Re: [TUHS] Re: UNIX on Tandem > > >>Tandem’s architecture was an interesting one, but I had > >>not heard of a UNIX port to it. Had it’s own, unlike anything else, > >>OS > >>called TOS or something. > > > >The operating system was called GUARDIAN. The manuals are available > >here: > > > >https://bitsavers.org/pdf/tandem/ > > > >And this is an SOSP’81 paper about the design of the operating system: > > > >https://doi.org/10.1145/800216.806587 From tuhs at tuhs.org Sat Jan 10 07:05:40 2026 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Fri, 9 Jan 2026 22:05:40 +0100 Subject: [TUHS] UNIX on Tandem In-Reply-To: References: Message-ID: <7FB2195E-E052-4EA1-9F6E-1AF38ECE31F7@alchemistowl.org> > On 9 Jan 2026, at 21:42, Warner Losh via TUHS wrote: > > I thought it was NONSTOP at one point... It was NONSTOP KERNEL (abbreviated NSK) in the ‘90 when Compaq/Digital bought them. Then HP bought them and it was all over. GUARDIAN was still there as was TACL. They were porting from MIPS to Alpha and then they were in the process of going to … Itanium (enter obligatory scream). Arrigo From tuhs at tuhs.org Sat Jan 10 08:42:04 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Sat, 10 Jan 2026 08:42:04 +1000 Subject: [TUHS] UNIX on Tandem In-Reply-To: <483199ae-845b-44db-931d-34ad89c2ffed@technologists.com> References: <483199ae-845b-44db-931d-34ad89c2ffed@technologists.com> Message-ID: I worked briefly with a non-stop set-up long after this. What sold them to corporates was (in my opinion) both fault tolerant design and an SLA. An australian engineer in telecommunications of that era told me they ran their metropolitan area network as a fault tolerant dual ring, and like tandem had to tell Sales droids to STOP pulling line cards (CPU cards for tandem) in front of prospective buyers, because it triggered an automatic fault report and spares shipment cross country. It's probably urban myth with an element of maybe true. Yes, the design was about redundancy but the sell was gold era IBM managed services: you bought a package. G On Sat, 10 Jan 2026, 4:42 am Charles H Sauer (he/him) via TUHS, < tuhs at tuhs.org> wrote: > On 1/9/2026 12:59 AM, Tom Lyon via TUHS wrote: > > Ran across this citation today. Anyone ever seen this paper? Known of > the > > system? I'm pretty sure they're talking about Tandem(TM), not just > > generic tandem. > > > > A Distributed UNIX System-The Tandem Experiment. A. M. Usas, Proc Natl > > Electron Conf, 34 (October 1980), pp 16-8. > > Doug Jewett and other people instrumental in the early days of AIX went > on to Tandem in Austin to create the Tandem S2 (MIPS-based) hardware and > a fault-tolerant reworked version of SVR3 for that hardware. > > Doug suggests that Peter Norwood's paper at > https://archive.org/details/tandemsr7-1/page/n11/mode/2up is likely the > best introduction. > > Doug also suggests "This paper touches on some of the hardware and the > software aspects of S2: D. Jewett, "Integrity S2: A Fault-Tolerant Unix > Platform," Proc. 21st International Symposium Fault-Tolerant Computing, > July 1991." However, I don't know of an accessible version of that > reference. > > Charlie > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/mas.to > : > CharlesHSauer > > From tuhs at tuhs.org Sun Jan 11 02:23:03 2026 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Sat, 10 Jan 2026 11:23:03 -0500 Subject: [TUHS] 3 minute clip from Al Aho about awk's original development In-Reply-To: <202601081325.608DP2jC096157@freefriends.org> References: <202601081325.608DP2jC096157@freefriends.org> Message-ID: That's nice, and consistent with my memory. That collaboration is how i managed to transfer into Research, for which i am eternally grateful. On Thu, Jan 8, 2026 at 8:25 AM Arnold Robbins via TUHS wrote: > > > https://www.youtube.com/watch?v=5Zsk5L225Zs From tuhs at tuhs.org Sun Jan 11 16:54:36 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sat, 10 Jan 2026 23:54:36 -0700 Subject: [TUHS] 3 minute clip from Al Aho about awk's original development In-Reply-To: References: <202601081325.608DP2jC096157@freefriends.org> Message-ID: <202601110654.60B6saVb065061@freefriends.org> Peter, If you don't mind my asking, what were you doing before Research? In truth, the question is deeper. We have videos from Ken with his history, Doug's oral history, and BWK's memoirs, but I (at least) know very little about you. So the question is more like, where did you get your education, how did you end up at Bell Labs, what did you do there before moving to Research? If you feel like answering, of course. Much thanks, Arnold Peter Weinberger (温博格) wrote: > That's nice, and consistent with my memory. That collaboration is how > i managed to transfer into Research, for which i am eternally > grateful. > > On Thu, Jan 8, 2026 at 8:25 AM Arnold Robbins via TUHS wrote: > > > > > > https://www.youtube.com/watch?v=5Zsk5L225Zs From tuhs at tuhs.org Sun Jan 11 22:24:31 2026 From: tuhs at tuhs.org (=?utf-8?q?Martin_Schr=C3=B6der_via_TUHS?=) Date: Sun, 11 Jan 2026 13:24:31 +0100 Subject: [TUHS] 3 minute clip from Al Aho about awk's original development In-Reply-To: <202601110654.60B6saVb065061@freefriends.org> References: <202601081325.608DP2jC096157@freefriends.org> <202601110654.60B6saVb065061@freefriends.org> Message-ID: Am So., 11. Jan. 2026 um 07:55 Uhr schrieb Arnold Robbins via TUHS : > If you don't mind my asking, what were you doing before Research? > > In truth, the question is deeper. We have videos from Ken with his > history, Doug's oral history, and BWK's memoirs, but I (at least) know > very little about you. So the question is more like, where did you > get your education, how did you end up at Bell Labs, what did you > do there before moving to Research? https://en.wikipedia.org/wiki/Peter_J._Weinberger "Weinberger was an undergraduate at Swarthmore College, graduating in 1964. He received his PhD in mathematics with a specialization in number theory in 1969 from the University of California, Berkeley under Derrick Henry Lehmer for his thesis Proof of a Conjecture of Gauss on Class Number Two. After holding a position in the Department of Mathematics at the University of Michigan, Ann Arbor, where he continued his work in analytic number theory, he moved to AT&T Bell Labs." Best Martin From tuhs at tuhs.org Mon Jan 12 03:37:18 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 11 Jan 2026 17:37:18 +0000 Subject: [TUHS] UNIX/32V Version 1.0 Programmer's Manual Scan Message-ID: Happy whichever time of day, I'd like to announce preservation of a scan of the UNIX/32V Programmer's Manual, Version 1.0. I wasn't aware of any paper scans of an original (non-BSD-ized) 32V manual, and came across a photo of this one while searching for some other stuff. At first my stomach jumped into my throat as I thought I was looking at a UNIX/TS Version 1.0 manual (the UNIX/32V was hidden behind the report cover). However, cross-referencing the dates and terminology soon revealed the truth. In any case, I contacted the poster and he indicated this was in a bookshelf at an institution he used to work in, and luckily was able to track the manual down. This would be the Department of Computer Science at Aberystwyth University (https://www.aber.ac.uk/en/cs). The story goes that they ordered 32V for a VAX 11/780 they acquired back in the day and kept at least this manual. There isn't any indication of them having a paper copy of Volume 2(A/B) unfortunately, but luckily the TROFF sources are in the 32V distro tape which is long since preserved. Without further ado, I've placed the scans here: https://www.tuhs.org/Archive/Documentation/Manuals/UNIX_32V_Version_1.0/ These are presented as each manual section along with the intro, covers, and the divider tabs as separate documents. I plan on mastering a combined, single PDF to mirror over on my archive.org UNIX collection as well, so keep an eye out for that. Enjoy! - Matt G. P.S. I've got another, much larger preservation job to share here very soon, so don't put your socks back on just yet! Hopefully I'll have the attribution details figured out by this afternoon and will be publishing that stuff too. More to come! From tuhs at tuhs.org Mon Jan 12 04:15:55 2026 From: tuhs at tuhs.org (Brian Stuart via TUHS) Date: Sun, 11 Jan 2026 18:15:55 +0000 Subject: [TUHS] 3 minute clip from Al Aho about awk's original development In-Reply-To: References: <202601081325.608DP2jC096157@freefriends.org> <202601110654.60B6saVb065061@freefriends.org> Message-ID: Very cool. I've come across Lehmer because of a very clever parallel prime number sieve he did on the ENIAC. He's also responsible for one of my favorite quotes, "The ENIAC was a wonderfully parallel machine until von Neumann spoiled it." BLS On Sun, Jan 11, 2026 at 12:31 PM Martin Schröder via TUHS wrote: > > Am So., 11. Jan. 2026 um 07:55 Uhr schrieb Arnold Robbins via TUHS > : > > If you don't mind my asking, what were you doing before Research? > > > > In truth, the question is deeper. We have videos from Ken with his > > history, Doug's oral history, and BWK's memoirs, but I (at least) know > > very little about you. So the question is more like, where did you > > get your education, how did you end up at Bell Labs, what did you > > do there before moving to Research? > > https://en.wikipedia.org/wiki/Peter_J._Weinberger > > "Weinberger was an undergraduate at Swarthmore College, graduating in > 1964. He received his PhD in mathematics with a specialization in > number theory in 1969 from the University of California, Berkeley > under Derrick Henry Lehmer for his thesis Proof of a Conjecture of > Gauss on Class Number Two. After holding a position in the Department > of Mathematics at the University of Michigan, Ann Arbor, where he > continued his work in analytic number theory, he moved to AT&T Bell > Labs." > > Best > Martin From tuhs at tuhs.org Mon Jan 12 04:40:59 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 11 Jan 2026 18:40:59 +0000 Subject: [TUHS] UNIX Reference Card (Was: Vi Quick Reference card for 4.4 BSD) In-Reply-To: References: <856fbc2c-f2a8-4671-a3ca-6aa89af86114@mhorton.net> <04b00f4d-d082-49af-a1ed-6c1730cd0b00@mhorton.net> Message-ID: > On Friday, January 9th, 2026 at 00:58, Jonathan Gray via TUHS tuhs at tuhs.org wrote: > > > On Wed, Jan 07, 2026 at 05:24:13PM -0800, Mary Ann Horton via TUHS wrote: > > > > I had some extra time today, so I went ahead and scanned the Cherry card and > > the Bolsky card. > > > > The Cherry card is unique in that the pages aren't all the same length. Each > > section has slightly longer pages, with a "tab" heading at the bottom of the > > first page of each section. See the 3rd page of the PDF for the full effect. > > > > https://stargatemuseum.org/maps/UNIX_Reference_Card_Second_Edition_by_L.L.Cherry.pdf > > > > https://stargatemuseum.org/maps/UNIX_System_Quick_Guide.pdf > > > > Thanks, > > > > /Mary Ann Horton/ (she/her/ma'am) > > Award Winning Author > > maryannhorton.com https://maryannhorton.com > > Thank you. I see Warren has also added these to the archive. > > https://www.tuhs.org/Archive/Documentation/Cards/ Just an update, I copied over a cleaner copy of the First Edition scan. The earlier one is now suffixed "_OCR" as it comes from archive.org's OCR derivation process. I'm not sure if there is a way to make quality hints to the derive but it mangled the quality. The new copy should be much more readable. This is all in the README now. - Matt G. From tuhs at tuhs.org Mon Jan 12 06:23:19 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 11 Jan 2026 20:23:19 +0000 Subject: [TUHS] Large USG Library Archive (And Some Extras) Message-ID: Hello once again everyone, I am proud to announce the publication of a number of documents scanned by Stephen Searle from his large collection of UNIX Support Group (USG) library documents from the 70s and 80s. Stephen worked under Ted Kowalski at Murray Hill and and then later at Piscataway, becoming friends with the technical librarian who then provided these and other documents. https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/ Among these documents is #1100, the UNIX Bibliography as maintained by USG. This lists out references to the other documents in this collection as well as the USG library numbers for other known and unknown documents. Even better, two revisions of the bibliography are present, as well as a number of other papers detailing the documentation efforts of systems such as Program Generic Issues 1 and 2, UNIX/TS, and PWB 2.0. All in all, much light is shed on early USG UNIX prior to System III. In addition, there are documents concerning BTLs microprocessor efforts, including use of Intellec MDS units, a MAC-8 software simulator, and the application of the IS25 assembly language to the MAC-80/BellMAC-32 project. Most interesting to me are some directory listings of the source files that make up USG Program Generic Issue 1 and 2. Unfortunately the full sources are not available, but the directory listings at least give an idea of what source files were present, making it possible to then identify what pages were added/altered in the manuals between Issue 1 and the preserved Issue 2 manual. Similarly, a list of MRs addressed in PWB 2.0 could be helpful in tandem with extant CB-UNIX literature to reconstruct a bit more fully what PWB 2.0 looked like. Anywho, exciting stuff, I'll probably start some separate threads on Program Generic, UNIX/TS, and PWB 2.0 findings derived from the new information here sometime in the coming weeks, I'm still pouring over the Program Generic source file descriptions heavily. ----- As mentioned, there are some extras. These are not from the same archival effort, rather, a few things I plucked from a box of misc documents I'm still sorting through. First is Bob Fabry's initial BSD proposal, describing the proposed additions and changes Berkeley intends to make to 32V: https://archive.org/details/proposal-to-provide-vax-unix-system-support-at-berkeley Second is the earliest C Reference Manual I've seen. I base this on the fact that the introduction states the IBM compiler is in the works. The earliest C Reference Manual I've seen before this stated that the IBM compiler was already in use. I think this makes this the earliest C Reference Manual now scanned: https://archive.org/details/c-reference-manual-1973 Discussion on these two can spin off separately, just figured I'd announce the next batch of documents together rather than a bunch of little threads. Enjoy! - Matt G. From tuhs at tuhs.org Mon Jan 12 08:21:39 2026 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Sun, 11 Jan 2026 23:21:39 +0100 Subject: [TUHS] Yacc binary on 4th edition tape Message-ID: <792DD77D-8BEB-4CC9-AFE6-F92C2F73BB1F@planet.nl> Jonathan Gray very kindly found two sources for “yopti” in the TUHS archives. The first is in the UNSW 110 archive (https://www.tuhs.org/Archive/Distributions/UNSW/110/). The archive is from 1981, but it appears to be the 1975 yacc of 6th edition. This yacc has the source for the optimizer ("yopti.c”). It reads the the y.tab.c file that plain 6th edition yacc generates, does some processing and writes out a new y.tab.c. It also comes with a new yyparse routine and this routine is essentially identical to the yyparse of 7th edition (which I think is more or less the final version of classic yacc). The other is in the PWB1 distribution (https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s2/yacc.d), from 1977. The optimizer is now in the source file "y5.c” and largely, but not fully the same. It has a new way to compress the “yyact” table. The y5.c file can build both as a separate program and as a subroutine of the yacc core, reusing table space from the earlier phases. The new way to compress is also used in 7th edition, but the optimizer has been fully integrated in the core yacc codebase. I’ve also disassembled the first part (y1.c) of the yacc binary in 4th edition. There is more instrumentation (regular calls to “times()” to track time spent) and there is no code to call out to an optimizer pass, suggesting that it might not have existed yet (but of course absence of proof is not proof of absence). The development of table sizes is interesting, in particular “yyact”; I have tested with the 1978 grammar for the Eh compiler. - The 1975 core yacc generates a yyact table with about 1650 entries. Here the yyparse routine has to do a lot of searching through the tables whilst parsing: the representation is compact, but slow to process. - The 1975 optimizer changes the table structure to avoid the searching (arriving at about the final form of “yaccpar”), but the yyact table that it produces is huge: the 1600 entries are expanded into almost 11,000 entries, many of which are “0”. Probably it was considered work-in-progress at this stage and hence not included on the 6th edition tape. (I had to fix one bug in yopti.c to get it to run; maybe this was a bad fix but at the moment I don’t think so.) - The algorithm in the 1977 PWB1 version is a spectacular improvement: the “yyact” table goes down in size to about 650 entries. Note that “yaccpar” does not change: it is ‘only' a superior algorithm to find the optimal compression of a sparse table. All in all, my hypothesis on the timeline would now be: - 1971: first version of yacc created in B - 1972: improvements to make it more practical - 1973: yacc introduced to Waterloo (relevant for Eh) - 1973: conversion from B to C - 1974: improvements on speeding up table generation - 1975: improvements on speeding up yyparse execution - 1976: improvement on reducing optimized table size - 1977/78: cleaning up code base, portability, tracking C changes - 1979: more or less final version of classic yacc The above matches with interviews with Johnson and Aho, where both say that yacc was improved over a number of years and with about a dozen rewrites in that period. ==== Now back to the timeline for the Waterloo Eh compiler. - I think it is a fact that the early B compiler on the Honeywell 6000 was a two-pass compiler, three if you count the assembler. Steve Johnsons writes "The './bj' command works as follows: the first two passes, ./b1 and ./b2, of the B compiler are run in MH-TSS. The result of the second pass of the compiler is a GMAP program, which must be sent to the batch world, compiled, and loaded with the B I/O library (on file ./blib) to create an executable H* file. The ./bj command calls ./b1 and ./b2, and if no errors are detected, the GMAP deck is submitted to the batch world; currently, this is done using 'jrun’.” (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/bref.html). I don’t know much about the H6000, but apparently GMAP is the system macro assembler. Not a fact, but I assume that the “b1” pass is Ken Thompson’s B front end (lexing, parsing, threaded/intermediate code generation) and the “b2” pass is Dennis Ritchie’s "tour de force" native code generator. - In November 1975 the Thoth project writes that they like the B compiler, and “this is largely due to the fact that it is a syntax directed compiler for a language which has a simple and compact syntax. The one-pass compiler is implemented in B.” This sounds like a different compiler. The B compiler above is clearly not one pass and only syntax directed in the sense that any compiler is syntax directed. This compiler remains a bit of a mystery. Maybe it is something that Steve Johnson wrote during his sabbatical there. - However, in February 1976 they write (CS-76-11): "As the first stage of the project, we have designed a high-level implementation language (called Eh) which will be common to all machines. […] The Eh compiler consists f two phases: the first phase does the syntax analysis and outputs intermediate language. The intermediate language resembles the order code for a stack oriented machine. During the second phase of compilation, the intermediate language is translated to the target machine language.”. This sounds like reverting to the structure of the original Honeywell B compiler, with the difference that it uses yacc in its front-end and the back-end outputs relocatable object code, not assembler source. [as an aside: the 1978 version of this Eh intermediate code is well documented and it has some intriguing similarities to the PDP-7 threaded code for B as reconstructed by AAP; it needs more investigation, but it suggests that the Eh intermediate code was influenced by the intermediate code between the b1 and b2 passes of the original H6000 B compiler.] The question now is what version of yacc they would have used for the Eh compiler. It may be the yacc that Steve Johnson brought to Waterloo in 1973, but in view of the above timeline, it was probably a bit unwieldy to use at that point in time. Another possibility is that they used yacc from Unix 6th edition (the Waterloo Math department had a PDP-11 running Unix), and back-ported that later to Eh later to make their tool chain self hosting. With V6 being dated around May 1975, it would stand to reason that they had V6 running by the end of that year. From what I understand so far, it is unlikely to have used the optimizer, as that appears to have been unpolished / unfinished until a bit later in time. From tuhs at tuhs.org Mon Jan 12 09:01:46 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Sun, 11 Jan 2026 15:01:46 -0800 Subject: [TUHS] Large USG Library Archive (And Some Extras) In-Reply-To: References: Message-ID: Awesome stuff. I see my own minor contribution gained Dennis as a co-author, but I've never seen that version, nor is it in the new stuff. SIgh. (1203) Inter-UNIX Portability T.L. Lyon + D.M. Ritchie TM 77-1273-13 September 16, 1977 On Sun, Jan 11, 2026 at 12:23 PM segaloco via TUHS wrote: > Hello once again everyone, I am proud to announce the publication of a > number of documents scanned by Stephen Searle from his large collection > of UNIX Support Group (USG) library documents from the 70s and 80s. > Stephen worked under Ted Kowalski at Murray Hill and and then later at > Piscataway, becoming friends with the technical librarian who then > provided these and other documents. > > https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/ > > Among these documents is #1100, the UNIX Bibliography as maintained by > USG. This lists out references to the other documents in this > collection as well as the USG library numbers for other known and > unknown documents. Even better, two revisions of the bibliography are > present, as well as a number of other papers detailing the documentation > efforts of systems such as Program Generic Issues 1 and 2, UNIX/TS, and > PWB 2.0. All in all, much light is shed on early USG UNIX prior to > System III. In addition, there are documents concerning BTLs > microprocessor efforts, including use of Intellec MDS units, a MAC-8 > software simulator, and the application of the IS25 assembly language > to the MAC-80/BellMAC-32 project. > > Most interesting to me are some directory listings of the source files > that make up USG Program Generic Issue 1 and 2. Unfortunately the full > sources are not available, but the directory listings at least give an > idea of what source files were present, making it possible to then > identify what pages were added/altered in the manuals between Issue 1 > and the preserved Issue 2 manual. Similarly, a list of MRs addressed in > PWB 2.0 could be helpful in tandem with extant CB-UNIX literature to > reconstruct a bit more fully what PWB 2.0 looked like. > > Anywho, exciting stuff, I'll probably start some separate threads on > Program Generic, UNIX/TS, and PWB 2.0 findings derived from the new > information here sometime in the coming weeks, I'm still pouring over > the Program Generic source file descriptions heavily. > > ----- > > As mentioned, there are some extras. These are not from the same > archival effort, rather, a few things I plucked from a box of misc > documents I'm still sorting through. > > First is Bob Fabry's initial BSD proposal, describing the proposed > additions and changes Berkeley intends to make to 32V: > > > https://archive.org/details/proposal-to-provide-vax-unix-system-support-at-berkeley > > Second is the earliest C Reference Manual I've seen. I base this on > the fact that the introduction states the IBM compiler is in the works. > The earliest C Reference Manual I've seen before this stated that the > IBM compiler was already in use. I think this makes this the earliest > C Reference Manual now scanned: > > https://archive.org/details/c-reference-manual-1973 > > Discussion on these two can spin off separately, just figured I'd > announce the next batch of documents together rather than a bunch of > little threads. > > Enjoy! > > - Matt G. > From tuhs at tuhs.org Mon Jan 12 10:56:42 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 12 Jan 2026 00:56:42 +0000 Subject: [TUHS] Some USG Program Generic Observations Message-ID: Lots of info pulled from the recent USG document dump incoming. Some of this is already known, but confirmed helpfully by documents here so pardon any repeat information. I thought I'd share a little writeup on early USG UNIX patterns observed in some of these documents. The first thing I've gleaned from this documentation is detail on the source code directory structure of USG's Program Generic line of UNIX, as well as how this line relates to earlier efforts by USG. First, USG's prior efforts were simply named "Releases", as is seen in both [1] and [2]. The former concerns the automated kernel build system "SYSGEN" which USG used for their kernels. Therein, the familiar structure under /usr/sys for kernel sources is seen. This would be between the Fourth and Fifth Edition. In June, 1974, the same month that the Fifth Edition manual is issued, a report is also issued[3] detailing the addition of comments to the source headers in USG UNIX. These comments do not show up until the Sixth Edition in the research stream so this may indicate the commentary added between those kernels originated with the USG. In any case, the main takeaway here is that USG's first go around with "Release" issues retained the source code structure of Research for the most part, but were not opposed to adding in their own changes. Both the Release 2 and Release 3 documents show the sources of various bits in the same place they are in Research UNIX. Once Program Generic comes into the picture in late 1975/early 1976, things change up a bit. A paper in 1974[4] establishes a suggested tree for source code that is quite different from the Research tree. Instead, different subsystems are isolated and all such subsystems, both kernel and user, are stored in /usr/source. This file structure is realized in file schedules for both Issue 1 and Issue 2 of Program Generic[5][6]. Between these and [4] it is possible to reconstruct the source file tree for both Issues. This gives then several insights into the differences in the Program Generic line. Issue 2 picks up the following new features: - Agen, An Associative Memory Generator (Described in [7]) - Bc - The familiar mathematics language - Cref - Cross reference lister - Lex - Lexical analyzer generator (Looks more like PWB than V7ish) - LIL - A little language - Neqn - Even better equations - Nroff - Even better typesetting - Portc - The Portable C Library - Sno - SNOBOL - Yacc - Yet another compiler compiler As well as the following changes: - Adds a fifth syscall file (sys5.c) to the kernel, presumably for USG kernel additions. - Ed, getty, ld, and mesg are all updated to C versions. These are all similarly moved to C between V5 and V6. - Added gsi, icheck, ichecks, wall, removes msh and tty, consistent with V5 -> V6 update. - Adds mtm, a magtape manipulation program. This remains in Issue 3 as well as CB-UNIX 2.1[8]. - The ov nroff filter is removed. This was not carried forward in research after V3. - Dropped the cat(4), draa(4), tiu(4), vs(4), and vt(4) drivers. - Picked up hp(4), hs(4), ht(4) drivers. - Picked up rh(4) driver. So much of this rings of the changes seen between V5 and V6 in research. This speaks to UNIX Program Generic Issue 1 being a more V5-ish experience whereas Issue 2 is on its way to V6. In any case, it sounds like Release 2 and Release 3 (pre-Program Generic) took after V4 a bit more. Interesting in this too is that this source code structure is seen, somewhat, in the PWB and CB-UNIX lines, but only in their kernel sources. This is seen in path names like io, os, ml, which are used for kernel system segregation in both the CB-UNIX and PWB/commercial line. However, sources are still in the s1/s2/s3/s4/etc. tree as of PWB1, then are in the V7-ish cmd/libc/sys(or uts) structure as of System III. This goes go show at least four source tree influences in C-UNIX: - PDP-11/45 Research (/usr/source, /usr/sys, kernel with ken/dmr paths) - USG (/usr/source/io1, /usr/source/opsys, /usr/source/cmd1) - PWB ($PREFIX/sys/ml, $PREFIX/sys/os, $PREFIX/sys/cf where $PREFIX=/sys PWB1, /usr PWB2) - V7 Research (/usr/src, /usr/sys, kernel with dev/sys paths) System III then sticks the kernel down in /usr/src/uts in a PWB-ish structure while everything else is V7-ish in directory structure. Hopefully whenever some PWB 2.0 and/or UNIX/TS documentation pop up the providence of the different ways of storing source code will be clearer. Thanks for following along, getting some solid info like this on the Program Generic line has been elusive for some time... - Matt G. [1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1060_SYSGEN_Shell_Procedure.pdf [2] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1017_Setting_Up_UNIX_Issue_Three.pdf [3] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1066_UNIX_Operating_System_Change_to_Header_Files.pdf [4] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1039_Reorganization_of_UNIX_Source_Files.pdf [5] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1040_UNIX_Operating_System_Generic_Program_Issue_1.pdf [6] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1046_UNIX_Support_Classifications_for_PG_1C300_Issue_2.pdf [7] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1064_Agen_An_Associative_Memory_Generator.pdf [8] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man1/mtm.1.pdf [9] - https://gitlab.com/segaloco/usg_pg_skeldiff From tuhs at tuhs.org Tue Jan 13 07:37:29 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Mon, 12 Jan 2026 16:37:29 -0500 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available Message-ID: Hello, Following the incredible recovery of the UNIX v4 tape from the University of Utah last month, I've written a comprehensive line-by-line commentary on the entire UNIX Fourth Edition source code. The book covers: - The kernel (boot, processes, memory management, scheduling) - The file system (inodes, buffer cache, namei) - Device drivers (TTY, RK05 disk, character devices) - User space (shell, utilities, C compiler, assembler) - Plus appendices with system call reference, file formats, and PDP-11 guide It's open source (CC BY-NC-SA 4.0) and available on GitHub: https://github.com/unix-v4-commentary/unix-v4-source-commentary The PDF is included in the repo for those who just want to read. It is my sincerest hope that this book can help someone, and I'd appreciate any feedback (and changes!). Many thanks to Robert Ricci, and Al Kossow, and everyone involved in recovering this historic code. Without that work, this book wouldn't have been possible. Also thanks to Mr. Warren for letting me in to the mailing list! Please don't beat me up too bad! Humbly yours, Briam Rodriguez From tuhs at tuhs.org Tue Jan 13 07:45:28 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Tue, 13 Jan 2026 07:45:28 +1000 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: On Mon, Jan 12, 2026 at 04:37:29PM -0500, Briam Rodriguez via TUHS wrote: > Following the incredible recovery of the UNIX v4 tape from the University > of Utah last month, I've written a comprehensive line-by-line commentary > on the entire UNIX Fourth Edition source code. > It is my sincerest hope that this book can help someone, and I'd appreciate > any feedback (and changes!). > Many thanks to Robert Ricci, and Al Kossow, and everyone involved in > recovering this historic code. > Without that work, this book wouldn't have been possible. Also thanks to Mr. > Warren for letting me in to the mailing list! > Please don't beat me up too bad! > Briam Rodriguez 8-) No beating required. I've skimmed the first two dozen pages and so far it's a good introduction to v4, setting the background in terms of people, organisations and the PDP-11 architecture. I'm sure that the TUHS members will give you well-advised and useful criticism and suggestions. Thanks for your hard work and effort Briam. Cheers, just Warren From tuhs at tuhs.org Tue Jan 13 08:52:22 2026 From: tuhs at tuhs.org (David Barto via TUHS) Date: Mon, 12 Jan 2026 14:52:22 -0800 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: <8EE87747-1EFC-49BC-87F4-308272F55191@kdbarto.org> Following up to my prior email. It does look like the PDF got created. Some 294 pages of it. Amazing. I can’t wait to read further. (At 4.4.4 now) David > On Jan 12, 2026, at 1:37 PM, Briam Rodriguez via TUHS wrote: > > Hello, > > Following the incredible recovery of the UNIX v4 tape from the University > of Utah last month, I've written a comprehensive line-by-line commentary > on the entire UNIX Fourth Edition source code. > > The book covers: > - The kernel (boot, processes, memory management, scheduling) > - The file system (inodes, buffer cache, namei) > - Device drivers (TTY, RK05 disk, character devices) > - User space (shell, utilities, C compiler, assembler) > - Plus appendices with system call reference, file formats, and PDP-11 guide > > It's open source (CC BY-NC-SA 4.0) and available on GitHub: > > https://github.com/unix-v4-commentary/unix-v4-source-commentary > > The PDF is included in the repo for those who just want to read. > > It is my sincerest hope that this book can help someone, and I'd appreciate any feedback (and changes!). > > Many thanks to Robert Ricci, and Al Kossow, and everyone involved in recovering this historic code. > > Without that work, this book wouldn't have been possible. Also thanks to Mr. Warren for letting me in to the mailing list! > > Please don't beat me up too bad! > > Humbly yours, > > Briam Rodriguez > From tuhs at tuhs.org Tue Jan 13 09:20:08 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Mon, 12 Jan 2026 18:20:08 -0500 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: <202601122320.60CNK8gc057239@ultimate.com> General question: Is "v4" really the right thing to call the tape? Page 1 footnote 1 reads UNIX Fourth Edition was released in November 1973. The source code in this book comes from a tape sent to the University of Utah in June 1974, containing the V4 distribution with minor updates. See Ken Thompson’s letter to Martin Newell dated May 31, 1974 While https://gunkies.org/wiki/UNIX_Fifth_Edition says v5 was dated June 1974. I understand the temptation to be the "John Lions of v5" and to be the first to plant a flag on heretofore unknown ground, but I'm more interested in understanding the tape in full context (what differences are seen between tape contents fall in relation to the extant v4 man pages, and the known "v5" sources?). I'd probably be more interested in short summaries of how the new tape differs from the Fourth Edition documentation, the "v5" sources, and finally v6, as documented by Lions. phil P.S. I'm probably just as, or more guilty of misnomering, since I may have helped propogate the term "version zero" for the recovered PDP-7 UNIX code when I was helping to bring it up and annotate it. P.P.S. Then there is the worm can of whether "Version" anything exists (the manual was published in editions, and tapes were made at various time) especially in earlier times... From tuhs at tuhs.org Tue Jan 13 09:50:48 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 12 Jan 2026 23:50:48 +0000 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: <202601122320.60CNK8gc057239@ultimate.com> References: <202601122320.60CNK8gc057239@ultimate.com> Message-ID: On Jan 12, 2026, at 16:20, Phil Budne wrote: > General question: Is "v4" really the right thing to call the tape? The manual editions are a messy way to refer to UNIX snapshots. UNIX was versioned by the manual releases, but the system was distributed as a copy of the current system on the Research machine, whenever the tape was cut. Different licensees received different snapshots, but the same manual. Since we only have a few snapshots now, it’s tempting to call them by the manual in use at the time, but it’s rather inaccurate. It’s much better to call them by some unique identifier; Utah V4 in this case or Dennis_v5, Henry_Spencer_v7, Nijmegen_v7, etc., as in the TUHS Archive. Or alternatively, to call it a UNIX V4 snapshot from 12 June 1974. As you say, the V5 manual is dated June 1974. The files on the Utah V4 tape are dated 12 June 1974 and documented to have been sent after May 1974, but with a V4 manual. So we’re looking at near-V5 code just days or weeks before the V5 manual was released. However, I continue to call it “V4”, as that is evidently what this particular tape was thought of as, since that was the manual version that accompanied it. Thalia From tuhs at tuhs.org Tue Jan 13 10:09:37 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 13 Jan 2026 00:09:37 +0000 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: <202601122320.60CNK8gc057239@ultimate.com> Message-ID: On Monday, January 12th, 2026 at 15:51, Thalia Archibald via TUHS wrote: > On Jan 12, 2026, at 16:20, Phil Budne wrote: > > > General question: Is "v4" really the right thing to call the tape? > > > > The manual editions are a messy way to refer to UNIX snapshots. > UNIX was versioned by the manual releases, but the system was distributed as a > copy of the current system on the Research machine, whenever the tape was cut. > Different licensees received different snapshots, but the same manual. > > Since we only have a few snapshots now, it’s tempting to call them by the manual > in use at the time, but it’s rather inaccurate. It’s much better to call them by > some unique identifier; Utah V4 in this case or Dennis_v5, Henry_Spencer_v7, > Nijmegen_v7, etc., as in the TUHS Archive. Or alternatively, to call it a UNIX > V4 snapshot from 12 June 1974. > > As you say, the V5 manual is dated June 1974. The files on the Utah V4 tape are > dated 12 June 1974 and documented to have been sent after May 1974, but with a > V4 manual. So we’re looking at near-V5 code just days or weeks before the V5 > manual was released. However, I continue to call it “V4”, as that is evidently > what this particular tape was thought of as, since that was the manual version > that accompanied it. > > Thalia The new USG docs refer to USGs providence as coming from a "frozen" machine. This does make me wonder why they didn't just start shipping USG UNIX instead since it was separated into "stable" releases. Granted either way they couldn't "support" it, but you'd figure it'd be easier for everyone to just keep sending out cuts of USG UNIX. Would it being AT&Ts internal supported UNIX make it too close to shipping a supported product and shipping random cuts from Research instead kept them out of scrutiny? They eventually warmed up to shipping PWB, so this remains a point of curiosity to me. - Matt G. From tuhs at tuhs.org Tue Jan 13 10:51:23 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Tue, 13 Jan 2026 00:51:23 +0000 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: Hello Briam, Thank you. This is like a Christmas present, even though it is now mid-January. As an amateur, I can only read the content and absorb. I know for sure, having already skimmed through a few pages, that I will enjoy reading it and learn much. Best regards, Cameron -------- Original Message -------- On Monday, 01/12/26 at 21:38 Briam Rodriguez via TUHS wrote: Hello, Following the incredible recovery of the UNIX v4 tape from the University of Utah last month, I've written a comprehensive line-by-line commentary on the entire UNIX Fourth Edition source code. The book covers: - The kernel (boot, processes, memory management, scheduling) - The file system (inodes, buffer cache, namei) - Device drivers (TTY, RK05 disk, character devices) - User space (shell, utilities, C compiler, assembler) - Plus appendices with system call reference, file formats, and PDP-11 guide It's open source (CC BY-NC-SA 4.0) and available on GitHub: https://github.com/unix-v4-commentary/unix-v4-source-commentary The PDF is included in the repo for those who just want to read. It is my sincerest hope that this book can help someone, and I'd appreciate any feedback (and changes!). Many thanks to Robert Ricci, and Al Kossow, and everyone involved in recovering this historic code. Without that work, this book wouldn't have been possible. Also thanks to Mr. Warren for letting me in to the mailing list! Please don't beat me up too bad! Humbly yours, Briam Rodriguez From tuhs at tuhs.org Tue Jan 13 11:21:25 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Tue, 13 Jan 2026 12:21:25 +1100 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: <792DD77D-8BEB-4CC9-AFE6-F92C2F73BB1F@planet.nl> References: <792DD77D-8BEB-4CC9-AFE6-F92C2F73BB1F@planet.nl> Message-ID: On Sun, Jan 11, 2026 at 11:21:39PM +0100, Paul Ruizendaal via TUHS wrote: > Jonathan Gray very kindly found two sources for “yopti” in the TUHS archives. > > The first is in the UNSW 110 archive (https://www.tuhs.org/Archive/Distributions/UNSW/110/). The archive is from 1981, but it appears to be the 1975 yacc of 6th edition. > > This yacc has the source for the optimizer ("yopti.c”). It reads the the y.tab.c file that plain 6th edition yacc generates, does some processing and writes out a new y.tab.c. It also comes with a new yyparse routine and this routine is essentially identical to the yyparse of 7th edition (which I think is more or less the final version of classic yacc). > > The other is in the PWB1 distribution (https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s2/yacc.d), from 1977. The optimizer is now in the source file "y5.c” and largely, but not fully the same. It has a new way to compress the “yyact” table. The y5.c file can build both as a separate program and as a subroutine of the yacc core, reusing table space from the earlier phases. The new way to compress is also used in 7th edition, but the optimizer has been fully integrated in the core yacc codebase. Also appears (without source) in a listing of files. Documentation/TechReports/USG_Library/ 1046_UNIX_Support_Classifications_for_PG_1C300_Issue_2.pdf UNIX Support Classifications for PG-1C300-1 Issue 2 January 30, 1976 opar.c yacc optimization parser yopti.c yacc optimizer postpass > All in all, my hypothesis on the timeline would now be: > > - 1971: first version of yacc created in B > - 1972: improvements to make it more practical > - 1973: yacc introduced to Waterloo (relevant for Eh) Unix Programmer's Manual, Third Edition, February 1973 YACC (VI) 1/20/73 mentions /crp/scj/bpar.b, output tables in actn.b "If your grammar is too big for yacc, you may try /crp/scj/bigyacc" > - 1973: conversion from B to C Unix Programmer's Manual, Fourth Edition, November 1973 YACC (VI) 6/6/73 no longer mentions b files > - 1974: improvements on speeding up table generation Unix Programmer's Manual, Sixth Edition, May 1975 YACC (I) 11/25/74 /usr/yacc/opar.c parser for optimized tables /usr/yacc/yopti optimizer postpass > - 1975: improvements on speeding up yyparse execution > - 1976: improvement on reducing optimized table size > - 1977/78: cleaning up code base, portability, tracking C changes > - 1979: more or less final version of classic yacc > > The above matches with interviews with Johnson and Aho, where both say that yacc was improved over a number of years and with about a dozen rewrites in that period. From tuhs at tuhs.org Tue Jan 13 11:22:27 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Mon, 12 Jan 2026 20:22:27 -0500 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: <77d574ac-f374-4952-b430-296db8d597ba@gmail.com> Thank you for your kind words, Cameron. I want you and all the lovely folks here to know how glad I am to be here, and that I take all feedback to heart. It's no mystery that the happenings of UNIX history were before my time, so I ask your patience with any errors or omissions; I'm approaching this as much as a historian as a programmer. But more than anything, this book is a mark of gratitude to K&R for making my livelihood possible. This is my way of attemping to contribute back to a community that has given me so much. -- Briam R. On 1/12/26 7:51 PM, Cameron Míċeál Tyre wrote: > Hello Briam, > > Thank you. This is like a Christmas present, even though it is now mid-January. As an amateur, I can only read the content and absorb. I know for sure, having already skimmed through a few pages, that I will enjoy reading it and learn much. > > Best regards, > > Cameron > > > > -------- Original Message -------- > On Monday, 01/12/26 at 21:38 Briam Rodriguez via TUHS wrote: > Hello, > > Following the incredible recovery of the UNIX v4 tape from the University > of Utah last month, I've written a comprehensive line-by-line commentary > on the entire UNIX Fourth Edition source code. > > The book covers: > - The kernel (boot, processes, memory management, scheduling) > - The file system (inodes, buffer cache, namei) > - Device drivers (TTY, RK05 disk, character devices) > - User space (shell, utilities, C compiler, assembler) > - Plus appendices with system call reference, file formats, and PDP-11 guide > > It's open source (CC BY-NC-SA 4.0) and available on GitHub: > > https://github.com/unix-v4-commentary/unix-v4-source-commentary > > The PDF is included in the repo for those who just want to read. > > It is my sincerest hope that this book can help someone, and I'd > appreciate any feedback (and changes!). > > Many thanks to Robert Ricci, and Al Kossow, and everyone involved in > recovering this historic code. > > Without that work, this book wouldn't have been possible. Also thanks to > Mr. Warren for letting me in to the mailing list! > > Please don't beat me up too bad! > > Humbly yours, > > Briam Rodriguez > > From tuhs at tuhs.org Tue Jan 13 11:34:52 2026 From: tuhs at tuhs.org (Mary Ann Horton via TUHS) Date: Mon, 12 Jan 2026 17:34:52 -0800 Subject: [TUHS] UNIX/32V Version 1.0 Programmer's Manual Scan In-Reply-To: References: Message-ID: Thank you for scanning this, Matt. My first thought was "I have a 32V manual". So I dug it out to compare. Yours is the official one, I guess, in the Bell System cover with tabs. Dated Feb 1979. Mine is what London and Reiser sent to Berkeley. Dated December 1978. It's almost identical, as it should be. But I have no tabs and a comb binding. I gather Berkeley got one copy and had it reproduced into many. (It also came with Vol 2A and 2B, dated December 1978. My copy is a do-it-yourself copy in a store-bought report cover.. My copy of vol 1 has a light blue cover with the following text: (at top) Bell Telephone Laboratories, Incorporated Holmdel, New Jersey (center of page) UNIX PROGRAMMER'S MANUAL Seventh Edition VAX-11 Version December 1979 It then proceeds to the Preface page (same as 00-intro page 3), Introduction to Volume 1 (00-intro page 5), a blank yellow page, Section 1 (03-man1), through to UPDATE(8), with blank yellow pages between sections. The back cover is blank, the same light blue as the front. It looks like we got a prerelease rather than the official 32V distribution. Thanks, /Mary Ann Horton/ (she/her/ma'am)       Award Winning Author maryannhorton.com On 1/11/26 09:37, segaloco via TUHS wrote: > Happy whichever time of day, I'd like to announce preservation of a scan > of the UNIX/32V Programmer's Manual, Version 1.0. I wasn't aware of any > paper scans of an original (non-BSD-ized) 32V manual, and came across > a photo of this one while searching for some other stuff. At first my > stomach jumped into my throat as I thought I was looking at a UNIX/TS > Version 1.0 manual (the UNIX/32V was hidden behind the report cover). > However, cross-referencing the dates and terminology soon revealed the > truth. > > In any case, I contacted the poster and he indicated this was in a > bookshelf at an institution he used to work in, and luckily was able to > track the manual down. This would be the Department of Computer Science > at Aberystwyth University (https://www.aber.ac.uk/en/cs). The story > goes that they ordered 32V for a VAX 11/780 they acquired back in the > day and kept at least this manual. There isn't any indication of them > having a paper copy of Volume 2(A/B) unfortunately, but luckily the > TROFF sources are in the 32V distro tape which is long since preserved. > > Without further ado, I've placed the scans here: > > https://www.tuhs.org/Archive/Documentation/Manuals/UNIX_32V_Version_1.0/ > > These are presented as each manual section along with the intro, covers, > and the divider tabs as separate documents. I plan on mastering a > combined, single PDF to mirror over on my archive.org UNIX collection as > well, so keep an eye out for that. > > Enjoy! > > - Matt G. > > P.S. I've got another, much larger preservation job to share here very > soon, so don't put your socks back on just yet! Hopefully I'll have the > attribution details figured out by this afternoon and will be publishing > that stuff too. More to come! From tuhs at tuhs.org Tue Jan 13 11:55:57 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 12 Jan 2026 20:55:57 -0500 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: <202601122320.60CNK8gc057239@ultimate.com> Message-ID: Below Sent from a handheld expect more typos than usual On Mon, Jan 12, 2026 at 7:09 PM segaloco via TUHS wrote: > On Monday, January 12th, 2026 at 15:51, Thalia Archibald via TUHS < > tuhs at tuhs.org> wrote: > > > On Jan 12, 2026, at 16:20, Phil Budne wrote: > > > > > General question: Is "v4" really the right thing to call the tape? > > > > > > > > The manual editions are a messy way to refer to UNIX snapshots. > > UNIX was versioned by the manual releases, but the system was > distributed as a > > copy of the current system on the Research machine, whenever the tape > was cut. > > Different licensees received different snapshots, but the same manual. > > > > Since we only have a few snapshots now, it’s tempting to call them by > the manual > > in use at the time, but it’s rather inaccurate. It’s much better to call > them by > > some unique identifier; Utah V4 in this case or Dennis_v5, > Henry_Spencer_v7, > > Nijmegen_v7, etc., as in the TUHS Archive. Or alternatively, to call it > a UNIX > > V4 snapshot from 12 June 1974. > > > > As you say, the V5 manual is dated June 1974. The files on the Utah V4 > tape are > > dated 12 June 1974 and documented to have been sent after May 1974, but > with a > > V4 manual. So we’re looking at near-V5 code just days or weeks before > the V5 > > manual was released. However, I continue to call it “V4”, as that is > evidently > > what this particular tape was thought of as, since that was the manual > version > > that accompanied it. > > > > Thalia > > The new USG docs refer to USGs providence as coming from a "frozen" > machine. This does make me wonder why they didn't just start shipping USG > UNIX instead since it was separated into "stable" releases. I think you are applying a thinking and are ignoring the realities of the time. Remember AT&T is under incredible scrutiny my the DOJ. They are prohibited from being in the computer business. USG’s charter is supporting the Bell System in a commercial manner. The last thing AT&T legal wants is to be seen using a commercial team to be creating “products” for the general market. Research >>is<< allowed (ney required) work with the research community. > > Granted either way they couldn't "support" it, but you'd figure it'd be > easier for everyone to just keep sending out cuts of USG UNIX. Would it > being AT&Ts internal supported UNIX make it too close to shipping a > supported product and shipping random cuts from Research instead kept them > out of scrutiny? They eventually warmed up to shipping PWB, so this > remains a point of curiosity to me. That really was a big deal during the 3.0 license negotiations. Al and Otis were very careful about what they were willing to make available outside of the Bell System. Once judge Green change the rules, The USG “Product” was easier To be made available > From tuhs at tuhs.org Tue Jan 13 12:00:29 2026 From: tuhs at tuhs.org (Jim Capp via TUHS) Date: Mon, 12 Jan 2026 21:00:29 -0500 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: I really like the first few pages. I look forward to a deeper dive. J > On Jan 12, 2026, at 4:37 PM, Briam Rodriguez via TUHS wrote: > > Hello, > > Following the incredible recovery of the UNIX v4 tape from the University > of Utah last month, I've written a comprehensive line-by-line commentary > on the entire UNIX Fourth Edition source code. > > The book covers: > - The kernel (boot, processes, memory management, scheduling) > - The file system (inodes, buffer cache, namei) > - Device drivers (TTY, RK05 disk, character devices) > - User space (shell, utilities, C compiler, assembler) > - Plus appendices with system call reference, file formats, and PDP-11 guide > > It's open source (CC BY-NC-SA 4.0) and available on GitHub: > > https://github.com/unix-v4-commentary/unix-v4-source-commentary > > The PDF is included in the repo for those who just want to read. > > It is my sincerest hope that this book can help someone, and I'd appreciate any feedback (and changes!). > > Many thanks to Robert Ricci, and Al Kossow, and everyone involved in recovering this historic code. > > Without that work, this book wouldn't have been possible. Also thanks to Mr. Warren for letting me in to the mailing list! > > Please don't beat me up too bad! > > Humbly yours, > > Briam Rodriguez > From tuhs at tuhs.org Tue Jan 13 14:37:51 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Tue, 13 Jan 2026 15:37:51 +1100 Subject: [TUHS] UNIX/32V Version 1.0 Programmer's Manual Scan In-Reply-To: References: Message-ID: Yes, some more on that: "we sent 32V to Berkeley. It was in October or November, 1978." Charlie Roberts in: Salus - A Quarter Century of UNIX, p 154 "The cooperation of Bell Laboratories in providing us with an early version of UNIX/32V is greatly appreciated. We would especially like to thank Dr. Charles Roberts of Bell Laboratories for helping us obtain this release, and acknowledge T. B. London and J. F. Reiser for their continuing advice and support." Ozalp Babaoglu, William Joy, Juan Porcar Design and Implementation of the Berkeley Virtual Memory Extensions to the UNIX Operating System https://www.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/doc/vmunix/design.t On Mon, Jan 12, 2026 at 05:34:52PM -0800, Mary Ann Horton via TUHS wrote: > > It looks like we got a prerelease rather than the official 32V distribution. From tuhs at tuhs.org Tue Jan 13 14:49:09 2026 From: tuhs at tuhs.org (Craig B Agricola via TUHS) Date: Mon, 12 Jan 2026 23:49:09 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 05, 2026 at 12:08:14PM -0500, Paul Winalski via TUHS wrote: > The problem with that philosophy is that a buffer overflow doesn't > necessarily lead to a program crash. A program crash is the lucky > outcome. If you're unlucky you will silently get the wrong answer, or > other misbehavior. In fact, in this case, far from just a program crash, you have a trivial privilege escalation. I'll repeat what I posted on the Metzdowd Cryptography list[1]. Since the buffer that you're comparing the crypt() of the input against is immediately after the buffer for the input, all you have to do is pad out the input to overwrite the hash that was read from /etc/passwd to the known hash of the beginning of your password input. crypt() of that era only takes into account the first 8 characters of the password. So, for instance, from an unprivileged user account, providing the following password to su gives you a root shell. abcdefghxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx5WWWWWWW: It's pretty quick to spin up a fresh simulator with the UNIX v4 tape install, create a user account, and then try to su with that password. -Craig 1. https://www.metzdowd.com/pipermail/cryptography/2026-January/039233.html From tuhs at tuhs.org Wed Jan 14 00:35:13 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Tue, 13 Jan 2026 09:35:13 -0500 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: Message-ID: On Mon, Jan 12, 2026 at 11:49 PM Craig B Agricola via TUHS wrote: > On Mon, Jan 05, 2026 at 12:08:14PM -0500, Paul Winalski via TUHS wrote: > > The problem with that philosophy is that a buffer overflow doesn't > > necessarily lead to a program crash. A program crash is the lucky > > outcome. If you're unlucky you will silently get the wrong answer, or > > other misbehavior. > > In fact, in this case, far from just a program crash, you have a trivial > privilege escalation. I'll repeat what I posted on the Metzdowd > Cryptography list[1]. > > Since the buffer that you're comparing the crypt() of the input against > is immediately after the buffer for the input, all you have to do is pad > out the input to overwrite the hash that was read from /etc/passwd to > the known hash of the beginning of your password input. crypt() of that > era only takes into account the first 8 characters of the password. So, > for instance, from an unprivileged user account, providing the following > password to su gives you a root shell. > > abcdefghxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx5WWWWWWW: > > It's pretty quick to spin up a fresh simulator with the UNIX v4 tape > install, create a user account, and then try to su with that password. I have a (very) vague memory that this was a known attack at some point in the past, but I no longer remember where I picked that up. Probably from discussions with the local sysadmins when I was in high school. - Dan C. From tuhs at tuhs.org Wed Jan 14 10:32:45 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 14 Jan 2026 10:32:45 +1000 Subject: [TUHS] Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <97fe5ae9-5080-126a-60c9-c1cfceaa58f9@makerlisp.com> References: <97fe5ae9-5080-126a-60c9-c1cfceaa58f9@makerlisp.com> Message-ID: On Mon, Jan 05, 2026 at 11:13:58AM -0700, Luther Johnson via TUHS wrote: > I think in the beginning it just wasn't considered that we had to protect > against programs intentionally doing harm. Who would do that? But now we > know. Some people knew back then too :-) https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V01.1.pdf (Oct 1978) page 13 has several good stories including one of a buffer overflow: Soon the "computniks" tired of "Cyber cracking" and turned their attention to UNIX. A super-user accidentally left the source mounted "readable by others" for about 30 minutes. In this time user file space soared (copies of source in various disguises) and a bug was discovered in "login" where password length was not checked properly and enabled a password of specific length to be entered followed by its known encryption. It took two days to clean up all the set-uid-root shells and spare source AND ALL IN 30 MINUTES!!!!! It's a good article to read from end to end. Cheers, Warren From tuhs at tuhs.org Wed Jan 14 11:53:20 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 14 Jan 2026 01:53:20 +0000 Subject: [TUHS] UNIX Cyclical (Dis)assembly Message-ID: Throughout the history of UNIX, various disassemblers have complemented the assemblers and other development tools the system is known for. In Research V1, for instance, a PDP-11 disassembler is described as: ------------------------------------------------------------------------ NAME das -- disassembler SYNOPSIS DESCRIPTION A PDP-11 disassembler exists. Contact the author for more information. FILES SEE ALSO DIAGNOSTICS BUGS OWNER ken ------------------------------------------------------------------------ At the far other end, System V's SGS includes a "dis" disassembler, which even makes it into the SVID as an optional feature of the software development tools. Nowadays, GNU binutils offers the objdump facility, and Microsoft ships dumpbin with their compiler suite. There are myriad of other small disassembly and code analysis tools out there, but for UNIX-like platforms and environments, there is what seems like a long trend of the disassembler being a standard inclusion in development tools, which I like. Something I'd certainly like some input on though is this: At any point was it expected of or otherwise designed into these disassemblers the requirement that the resulting code be compatible with the assembler for that same system? In other words, for SGS, was there much expectation that you could take what dis spits out and run it through as, getting a 1:1 product? Or at other times in the history of the system, was it commonplace to have this level of ease in reproducing source code from a binary with standard development tools? The debugger comes to mind as another utility often capable of reproducing assembly. - Matt G. From tuhs at tuhs.org Thu Jan 15 11:44:19 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Wed, 14 Jan 2026 20:44:19 -0500 Subject: [TUHS] CCI POWER 6/32 | Harris HCX-[579] | Unisys 7000/40 Message-ID: A colleague asked for this manual: "Does anyone have an architecture manual / processor manual / whatever this document would be called for this system, for the CCI POWER 6/32 (or any of it's rebadgings, like the Harris HCX-[579], or the Unisys 7000/40), that they'd be open to parting with? This appears to be completely unobtainium out in the usual places you'd expect to look for such things." This is the obvious place to ask. Best, Marc ===== mindthegapdialogs.com north-fork.info From tuhs at tuhs.org Thu Jan 15 23:24:44 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Thu, 15 Jan 2026 08:24:44 -0500 (EST) Subject: [TUHS] CCI POWER 6/32 | Harris HCX-[579] | Unisys 7000/40 Message-ID: <20260115132444.56D0618C087@mercury.lcs.mit.edu> > From: Marc Donner > A colleague asked for this manual: > "Does anyone have an architecture manual / processor manual ... for > this system, for the CCI POWER 6/32 (or any of it's rebadgings If one (or _anything_) turns up, it's _crucial_ that it be scanned, and the scans sent to Bitsavers!!! Almost nothing is known of this historically-important machine - the first thing other than a VAX that BSD was ported to. I did a fair amount of scratching around, and starting with the toolchain (mostly the debugger), which still exists, I was able to retrieve enough to give us a decent idea of the machine: https://gunkies.org/wiki/Power_6/32 There was discussion of trying to create an emulator, from the info in the toolchain: https://gunkies.org/wiki/Talk:Power_6/32 I was able to work out, from the instruction decode stuff in the debugger, what the instructions look like (fields, etc): but that still doesn't tell us what all the instructions _do_, at the level of detail that would be needed for successful emulation. We'd really need that manual! There is also "Installing and Operating BSD UNIX on the Tahoe", linked from the above. Noel From tuhs at tuhs.org Thu Jan 15 23:41:28 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Thu, 15 Jan 2026 14:41:28 +0100 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: Looks very nice, thanks! I was wondering about the RK driver, because there are issues with it. The v4 RK11 driver does not work with simh emulation correctly when using multiple disks. I've had to use the v5 driver for my v4 installation guide to get a usable system. Looking at the code i had the impression that the v4 driver is fine (it also matches the nsys RK driver, which i've also had trouble with recently. haven't tried v5 RK with nsys yet). What i suspect is happening is that the seek/read dance isn't working correctly, either in simh, or there were faulty assumptions that only work on real hardware more or less accidentially (the rewrite in v5 might suggest the latter). In any case it looks like blocks aren't being read correctly, and whatever process is waiting for the read will hang. Would be nice to get to the bottom of this. cheers, aap On 12/01/26, Briam Rodriguez via TUHS wrote: > Hello, > > Following the incredible recovery of the UNIX v4 tape from the University > of Utah last month, I've written a comprehensive line-by-line commentary > on the entire UNIX Fourth Edition source code. > > The book covers: > - The kernel (boot, processes, memory management, scheduling) > - The file system (inodes, buffer cache, namei) > - Device drivers (TTY, RK05 disk, character devices) > - User space (shell, utilities, C compiler, assembler) > - Plus appendices with system call reference, file formats, and PDP-11 guide > > It's open source (CC BY-NC-SA 4.0) and available on GitHub: > > https://github.com/unix-v4-commentary/unix-v4-source-commentary > > The PDF is included in the repo for those who just want to read. > > It is my sincerest hope that this book can help someone, and I'd > appreciate any feedback (and changes!). > > Many thanks to Robert Ricci, and Al Kossow, and everyone involved in > recovering this historic code. > > Without that work, this book wouldn't have been possible. Also thanks to > Mr. Warren for letting me in to the mailing list! > > Please don't beat me up too bad! > > Humbly yours, > > Briam Rodriguez > From tuhs at tuhs.org Thu Jan 15 23:44:31 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 15 Jan 2026 08:44:31 -0500 Subject: [TUHS] CCI POWER 6/32 | Harris HCX-[579] | Unisys 7000/40 In-Reply-To: <20260115132444.56D0618C087@mercury.lcs.mit.edu> References: <20260115132444.56D0618C087@mercury.lcs.mit.edu> Message-ID: Noel, Thank you. This is wonderful work. I have asked Keith and Kirk if they have anything that might be helpful. Clem Sent from a handheld expect more typos than usual On Thu, Jan 15, 2026 at 8:24 AM Noel Chiappa via TUHS wrote: > > From: Marc Donner > > > A colleague asked for this manual: > > "Does anyone have an architecture manual / processor manual ... for > > this system, for the CCI POWER 6/32 (or any of it's rebadgings > > If one (or _anything_) turns up, it's _crucial_ that it be scanned, and the > scans sent to Bitsavers!!! Almost nothing is known of this > historically-important machine - the first thing other than a VAX that BSD > was ported to. > > > I did a fair amount of scratching around, and starting with the toolchain > (mostly the debugger), which still exists, I was able to retrieve enough to > give us a decent idea of the machine: > > https://gunkies.org/wiki/Power_6/32 > > There was discussion of trying to create an emulator, from the info in > the toolchain: > > https://gunkies.org/wiki/Talk:Power_6/32 > > I was able to work out, from the instruction decode stuff in the debugger, > what the instructions look like (fields, etc): but that still doesn't tell > us what all the instructions _do_, at the level of detail that would be > needed > for successful emulation. We'd really need that manual! > > There is also "Installing and Operating BSD UNIX on the Tahoe", linked from > the above. > > Noel > From tuhs at tuhs.org Thu Jan 15 23:54:27 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Thu, 15 Jan 2026 08:54:27 -0500 Subject: [TUHS] CCI POWER 6/32 | Harris HCX-[579] | Unisys 7000/40 In-Reply-To: <20260115132444.56D0618C087@mercury.lcs.mit.edu> References: <20260115132444.56D0618C087@mercury.lcs.mit.edu> Message-ID: Thank you, Noel! ===== mindthegapdialogs.com north-fork.info On Thu, Jan 15, 2026, 08:25 Noel Chiappa via TUHS wrote: > > From: Marc Donner > > > A colleague asked for this manual: > > "Does anyone have an architecture manual / processor manual ... for > > this system, for the CCI POWER 6/32 (or any of it's rebadgings > > If one (or _anything_) turns up, it's _crucial_ that it be scanned, and the > scans sent to Bitsavers!!! Almost nothing is known of this > historically-important machine - the first thing other than a VAX that BSD > was ported to. > > > I did a fair amount of scratching around, and starting with the toolchain > (mostly the debugger), which still exists, I was able to retrieve enough to > give us a decent idea of the machine: > > https://gunkies.org/wiki/Power_6/32 > > There was discussion of trying to create an emulator, from the info in > the toolchain: > > https://gunkies.org/wiki/Talk:Power_6/32 > > I was able to work out, from the instruction decode stuff in the debugger, > what the instructions look like (fields, etc): but that still doesn't tell > us what all the instructions _do_, at the level of detail that would be > needed > for successful emulation. We'd really need that manual! > > There is also "Installing and Operating BSD UNIX on the Tahoe", linked from > the above. > > Noel > From tuhs at tuhs.org Fri Jan 16 04:08:01 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Thu, 15 Jan 2026 13:08:01 -0500 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: Angelo, I took a look at the v4 RK driver source to see what might be going on here. The v4 driver does something clever with multiple disks: overlapped seeks. When rkstart() runs, it iterates through all four drive queues and fires off SEEK commands for every drive that has pending work. The idea is that while drive 0 is seeking, drive 1 can be transferring data. Good for throughput on real hardware. The tricky part is the interrupt handler. When an interrupt comes in, rkintr() checks the SEEKCMP bit in rkcs to figure out if this is a "seek finished" or "transfer finished" interrupt. For seek completion, it reads bits 13-15 of rkds to determine which drive just finished seeking, then kicks off the actual data transfer for that drive. There's a global variable rk_ap that tracks which drive queue is currently mid-transfer. It gets set when a seek completes and used when the subsequent transfer completes. This is the state that ties the two-phase operation together. My theory: SIMH isn't correctly emulating the behavior when multiple seeks complete at the same (or nearly the same) simulated time. On real hardware, you'd get separate interrupts as each drive's seek finishes, with rkds properly reflecting which drive triggered each interrupt. But in emulation, if two seeks "complete simultaneously," you might only get one interrupt, or rkds might only reflect one of the drives. If that happens, the other drive's seek completion never triggers devstart(), so its read/write never actually happens. The process waiting in iowait() sleeps forever on B_DONE that never gets set. Hung process, exactly as you're seeing. The busy-waits in the driver (waiting for CTLRDY after commands, waiting for DRY|ARDY in error recovery) could also be problematic if the emulated status bits don't update with the timing the code expects. This would explain why v5 works: if they rewrote it to serialize operations more conservatively, or changed the state machine to not depend on precise interrupt ordering, the emulation timing issues wouldn't matter as much. Might be worth instrumenting rkintr() to log the rkcs and rkds values on each interrupt, and see if the drive identification is coming through correctly when multiple disks are in use. cheers -- Briam R. On 1/15/26 8:41 AM, Angelo Papenhoff via TUHS wrote: > I was wondering about the RK driver, because there are issues with it. > The v4 RK11 driver does not work with simh emulation correctly when > using multiple disks. I've had to use the v5 driver for my v4 > installation guide to get a usable system. Looking at the code i had the > impression that the v4 driver is fine (it also matches the nsys RK > driver, which i've also had trouble with recently. haven't tried v5 RK > with nsys yet). What i suspect is happening is that the seek/read dance > isn't working correctly, either in simh, or there were faulty > assumptions that only work on real hardware more or less accidentially > (the rewrite in v5 might suggest the latter). > In any case it looks like blocks aren't being read correctly, and > whatever process is waiting for the read will hang. > > Would be nice to get to the bottom of this. > > cheers, > aap From tuhs at tuhs.org Fri Jan 16 05:44:04 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Fri, 16 Jan 2026 05:44:04 +1000 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: If you patch an OS to run on a buggy simulator you're corrupting source to fix non existent bugs in that source. The fix is to get simh to respect interrupt signalling surely? Pragmatism says fix the v4 code, sure. G On Fri, 16 Jan 2026, 4:08 am Briam Rodriguez via TUHS, wrote: > Angelo, > > I took a look at the v4 RK driver source to see what might be going on > here. > > The v4 driver does something clever with multiple disks: overlapped > seeks. When rkstart() runs, it iterates through all four drive queues > and fires off SEEK commands for every drive that has pending work. The > idea is that while drive 0 is seeking, drive 1 can be transferring data. > Good for throughput on real hardware. > > The tricky part is the interrupt handler. When an interrupt comes in, > rkintr() checks the SEEKCMP bit in rkcs to figure out if this is a "seek > finished" or "transfer finished" interrupt. For seek completion, it > reads bits 13-15 of rkds to determine which drive just finished seeking, > then kicks off the actual data transfer for that drive. > > There's a global variable rk_ap that tracks which drive queue is > currently mid-transfer. It gets set when a seek completes and used when > the subsequent transfer completes. This is the state that ties the > two-phase operation together. > > My theory: SIMH isn't correctly emulating the behavior when multiple > seeks complete at the same (or nearly the same) simulated time. On real > hardware, you'd get separate interrupts as each drive's seek finishes, > with rkds properly reflecting which drive triggered each interrupt. But > in emulation, if two seeks "complete simultaneously," you might only get > one interrupt, or rkds might only reflect one of the drives. > > If that happens, the other drive's seek completion never triggers > devstart(), so its read/write never actually happens. The process > waiting in iowait() sleeps forever on B_DONE that never gets set. Hung > process, exactly as you're seeing. > > The busy-waits in the driver (waiting for CTLRDY after commands, waiting > for DRY|ARDY in error recovery) could also be problematic if the > emulated status bits don't update with the timing the code expects. > > This would explain why v5 works: if they rewrote it to serialize > operations more conservatively, or changed the state machine to not > depend on precise interrupt ordering, the emulation timing issues > wouldn't matter as much. > > Might be worth instrumenting rkintr() to log the rkcs and rkds values on > each interrupt, and see if the drive identification is coming through > correctly when multiple disks are in use. > > cheers > > -- Briam R. > > On 1/15/26 8:41 AM, Angelo Papenhoff via TUHS wrote: > > I was wondering about the RK driver, because there are issues with it. > > The v4 RK11 driver does not work with simh emulation correctly when > > using multiple disks. I've had to use the v5 driver for my v4 > > installation guide to get a usable system. Looking at the code i had the > > impression that the v4 driver is fine (it also matches the nsys RK > > driver, which i've also had trouble with recently. haven't tried v5 RK > > with nsys yet). What i suspect is happening is that the seek/read dance > > isn't working correctly, either in simh, or there were faulty > > assumptions that only work on real hardware more or less accidentially > > (the rewrite in v5 might suggest the latter). > > In any case it looks like blocks aren't being read correctly, and > > whatever process is waiting for the read will hang. > > > > Would be nice to get to the bottom of this. > > > > cheers, > > aap > From tuhs at tuhs.org Fri Jan 16 05:47:46 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Thu, 15 Jan 2026 14:47:46 -0500 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: <5d2bf30c-1cb7-4356-8a59-a52871673c64@gmail.com> George, To be clear, I'm not advocating patching v4 to work around emulator bugs. My email was purely diagnostic - trying to figure out /where/ the bug actually lives. If the issue is SIMH not correctly handling overlapped seeks and interrupt coalescing, then yes, SIMH should be fixed. But before anyone fixes anything, it helps to understand the failure mode. That's all I was doing: reading the driver code and theorizing about what timing assumptions might not hold under emulation. The suggestion to instrument rkintr() was to /confirm/ whether the emulator is the culprit, not to change the driver logic. cheers, Briam On 1/15/26 2:44 PM, George Michaelson via TUHS wrote: > If you patch an OS to run on a buggy simulator you're corrupting source to > fix non existent bugs in that source. > > The fix is to get simh to respect interrupt signalling surely? > > Pragmatism says fix the v4 code, sure. > > G > > On Fri, 16 Jan 2026, 4:08 am Briam Rodriguez via TUHS, > wrote: > >> Angelo, >> >> I took a look at the v4 RK driver source to see what might be going on >> here. >> >> The v4 driver does something clever with multiple disks: overlapped >> seeks. When rkstart() runs, it iterates through all four drive queues >> and fires off SEEK commands for every drive that has pending work. The >> idea is that while drive 0 is seeking, drive 1 can be transferring data. >> Good for throughput on real hardware. >> >> The tricky part is the interrupt handler. When an interrupt comes in, >> rkintr() checks the SEEKCMP bit in rkcs to figure out if this is a "seek >> finished" or "transfer finished" interrupt. For seek completion, it >> reads bits 13-15 of rkds to determine which drive just finished seeking, >> then kicks off the actual data transfer for that drive. >> >> There's a global variable rk_ap that tracks which drive queue is >> currently mid-transfer. It gets set when a seek completes and used when >> the subsequent transfer completes. This is the state that ties the >> two-phase operation together. >> >> My theory: SIMH isn't correctly emulating the behavior when multiple >> seeks complete at the same (or nearly the same) simulated time. On real >> hardware, you'd get separate interrupts as each drive's seek finishes, >> with rkds properly reflecting which drive triggered each interrupt. But >> in emulation, if two seeks "complete simultaneously," you might only get >> one interrupt, or rkds might only reflect one of the drives. >> >> If that happens, the other drive's seek completion never triggers >> devstart(), so its read/write never actually happens. The process >> waiting in iowait() sleeps forever on B_DONE that never gets set. Hung >> process, exactly as you're seeing. >> >> The busy-waits in the driver (waiting for CTLRDY after commands, waiting >> for DRY|ARDY in error recovery) could also be problematic if the >> emulated status bits don't update with the timing the code expects. >> >> This would explain why v5 works: if they rewrote it to serialize >> operations more conservatively, or changed the state machine to not >> depend on precise interrupt ordering, the emulation timing issues >> wouldn't matter as much. >> >> Might be worth instrumenting rkintr() to log the rkcs and rkds values on >> each interrupt, and see if the drive identification is coming through >> correctly when multiple disks are in use. >> >> cheers >> >> -- Briam R. >> >> On 1/15/26 8:41 AM, Angelo Papenhoff via TUHS wrote: >>> I was wondering about the RK driver, because there are issues with it. >>> The v4 RK11 driver does not work with simh emulation correctly when >>> using multiple disks. I've had to use the v5 driver for my v4 >>> installation guide to get a usable system. Looking at the code i had the >>> impression that the v4 driver is fine (it also matches the nsys RK >>> driver, which i've also had trouble with recently. haven't tried v5 RK >>> with nsys yet). What i suspect is happening is that the seek/read dance >>> isn't working correctly, either in simh, or there were faulty >>> assumptions that only work on real hardware more or less accidentially >>> (the rewrite in v5 might suggest the latter). >>> In any case it looks like blocks aren't being read correctly, and >>> whatever process is waiting for the read will hang. >>> >>> Would be nice to get to the bottom of this. >>> >>> cheers, >>> aap From tuhs at tuhs.org Fri Jan 16 07:20:59 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 15 Jan 2026 16:20:59 -0500 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: <5d2bf30c-1cb7-4356-8a59-a52871673c64@gmail.com> References: <5d2bf30c-1cb7-4356-8a59-a52871673c64@gmail.com> Message-ID: Plus remember that V6 and V7 work fine and they do overlapped I/O also. I’ll believe it’s possible for SIMH to be broken (hey UNIX had a history of exposing HW issues that the DEC OSs and diagnostics, did not). But I think we need to show Bob the issue (I’ve sent him a heads up). Sent from a handheld expect more typos than usual On Thu, Jan 15, 2026 at 2:48 PM Briam Rodriguez via TUHS wrote: > George, > > To be clear, I'm not advocating patching v4 to work around emulator > bugs. My email was purely diagnostic - trying to figure out /where/ the > bug actually lives. > > If the issue is SIMH not correctly handling overlapped seeks and > interrupt coalescing, then yes, SIMH should be fixed. But before anyone > fixes anything, it helps to understand the failure mode. That's all I > was doing: reading the driver code and theorizing about what timing > assumptions might not hold under emulation. > > The suggestion to instrument rkintr() was to /confirm/ whether the > emulator is the culprit, not to change the driver logic. > > cheers, Briam > > On 1/15/26 2:44 PM, George Michaelson via TUHS wrote: > > If you patch an OS to run on a buggy simulator you're corrupting source > to > > fix non existent bugs in that source. > > > > The fix is to get simh to respect interrupt signalling surely? > > > > Pragmatism says fix the v4 code, sure. > > > > G > > > > On Fri, 16 Jan 2026, 4:08 am Briam Rodriguez via TUHS, > > wrote: > > > >> Angelo, > >> > >> I took a look at the v4 RK driver source to see what might be going on > >> here. > >> > >> The v4 driver does something clever with multiple disks: overlapped > >> seeks. When rkstart() runs, it iterates through all four drive queues > >> and fires off SEEK commands for every drive that has pending work. The > >> idea is that while drive 0 is seeking, drive 1 can be transferring data. > >> Good for throughput on real hardware. > >> > >> The tricky part is the interrupt handler. When an interrupt comes in, > >> rkintr() checks the SEEKCMP bit in rkcs to figure out if this is a "seek > >> finished" or "transfer finished" interrupt. For seek completion, it > >> reads bits 13-15 of rkds to determine which drive just finished seeking, > >> then kicks off the actual data transfer for that drive. > >> > >> There's a global variable rk_ap that tracks which drive queue is > >> currently mid-transfer. It gets set when a seek completes and used when > >> the subsequent transfer completes. This is the state that ties the > >> two-phase operation together. > >> > >> My theory: SIMH isn't correctly emulating the behavior when multiple > >> seeks complete at the same (or nearly the same) simulated time. On real > >> hardware, you'd get separate interrupts as each drive's seek finishes, > >> with rkds properly reflecting which drive triggered each interrupt. But > >> in emulation, if two seeks "complete simultaneously," you might only get > >> one interrupt, or rkds might only reflect one of the drives. > >> > >> If that happens, the other drive's seek completion never triggers > >> devstart(), so its read/write never actually happens. The process > >> waiting in iowait() sleeps forever on B_DONE that never gets set. Hung > >> process, exactly as you're seeing. > >> > >> The busy-waits in the driver (waiting for CTLRDY after commands, waiting > >> for DRY|ARDY in error recovery) could also be problematic if the > >> emulated status bits don't update with the timing the code expects. > >> > >> This would explain why v5 works: if they rewrote it to serialize > >> operations more conservatively, or changed the state machine to not > >> depend on precise interrupt ordering, the emulation timing issues > >> wouldn't matter as much. > >> > >> Might be worth instrumenting rkintr() to log the rkcs and rkds values on > >> each interrupt, and see if the drive identification is coming through > >> correctly when multiple disks are in use. > >> > >> cheers > >> > >> -- Briam R. > >> > >> On 1/15/26 8:41 AM, Angelo Papenhoff via TUHS wrote: > >>> I was wondering about the RK driver, because there are issues with it. > >>> The v4 RK11 driver does not work with simh emulation correctly when > >>> using multiple disks. I've had to use the v5 driver for my v4 > >>> installation guide to get a usable system. Looking at the code i had > the > >>> impression that the v4 driver is fine (it also matches the nsys RK > >>> driver, which i've also had trouble with recently. haven't tried v5 RK > >>> with nsys yet). What i suspect is happening is that the seek/read dance > >>> isn't working correctly, either in simh, or there were faulty > >>> assumptions that only work on real hardware more or less accidentially > >>> (the rewrite in v5 might suggest the latter). > >>> In any case it looks like blocks aren't being read correctly, and > >>> whatever process is waiting for the read will hang. > >>> > >>> Would be nice to get to the bottom of this. > >>> > >>> cheers, > >>> aap From tuhs at tuhs.org Fri Jan 16 16:54:29 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Fri, 16 Jan 2026 06:54:29 +0000 Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? Message-ID: In Mahoney's oral history, he writes that after the PDP-7, "The file system was then put on a PDP-10". And in Thompson's 1989 interview with Mahoney, he mentions that "Before the 11/45 was available we bought a PDP-11 that had PDP-10 memory management, KS-1, it was a one of a kind machine". Are these the same system? I've never seen any other references to a PDP-10 used in early UNIX development, only that their request for a 10 was denied. Does anyone know anything about this strange PDP-11 + KS-1? What was the model of PDP-11 first used for UNIX? What hardware was sold by the UNIX group to the patent department? I presume it was an 11, since the 7 was never their property. Mahoney's words: When Thompson realized that the PDP-7 was not powerful enough to implement a file system that could offer some of the advantages of Multics he initially programmed a bare-bones file system. The file system was then put on a PDP-10. Using this enhanced capability, Thompson and the others slowly added tools that helped them monitor what the file system was doing. Thompson devoted a month apiece to the shell, editor, assembler, and other software tools. When asked when he realized that a new operating system was being born, Thompson replied, https://dspinellis.github.io/oral-history-of-unix/frs122/unixhist/finalhis.htm My summarization of the relevant paragraphs of Thompson's 1989 interview: After the PDP-7 was at the end of its life, they needed a new machine, so they proposed to buy a PDP-11 model that was about to be announced. The proposal was rejected, but the psychology research department decided to buy it and give it to them. They placed the new PDP-11 in Osanna's office next to the PDP-7 and wrote cross tools. They wrote a PDP-11 assembler on the 7 in B and ran the paper tape across the floor to the 11. For its first month, the 11 was without a disk, so they had a fake in-memory filesystem. Once it was delivered, they got UNIX running on it in about a week and, at this point, the topology of the directory structure was rather fixed. When the patent department was about to buy AstroText, a horrific and expensive typesetting package, they instead produced a version of nroff/troff for their specific formatting needs. They also talked the patent department into buying their system, i.e., the physical hardware, and moving it out. With that money, they bought an 11/45. Before the 11/45 was available, they bought a PDP-11 that had PDP-10 memory management, KS-1, a one-of-a-kind machine. This was the first time they were using the machine at the same time for program development as typists. https://dspinellis.github.io/oral-history-of-unix/mike/transcripts/thompson.htm Thalia From tuhs at tuhs.org Fri Jan 16 16:57:38 2026 From: tuhs at tuhs.org (Ken Thompson via TUHS) Date: Thu, 15 Jan 2026 22:57:38 -0800 Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? In-Reply-To: References: Message-ID: after the pdp-7, unix was ported to more stock pdp-9 and pdp15 (both pdp7 upgrades) no pdp-10 at bell labs. On Thu, Jan 15, 2026 at 10:54 PM Thalia Archibald via TUHS wrote: > In Mahoney's oral history, he writes that after the PDP-7, "The file > system was > then put on a PDP-10". And in Thompson's 1989 interview with Mahoney, he > mentions that "Before the 11/45 was available we bought a PDP-11 that had > PDP-10 > memory management, KS-1, it was a one of a kind machine". > > Are these the same system? I've never seen any other references to a > PDP-10 used > in early UNIX development, only that their request for a 10 was denied. > Does > anyone know anything about this strange PDP-11 + KS-1? > > What was the model of PDP-11 first used for UNIX? What hardware was sold > by the > UNIX group to the patent department? I presume it was an 11, since the 7 > was > never their property. > > Mahoney's words: > > When Thompson realized that the PDP-7 was not powerful enough to > implement a > file system that could offer some of the advantages of Multics he > initially > programmed a bare-bones file system. The file system was then put on a > PDP-10. Using this enhanced capability, Thompson and the others slowly > added > tools that helped them monitor what the file system was doing. Thompson > devoted a month apiece to the shell, editor, assembler, and other > software > tools. When asked when he realized that a new operating system was > being > born, Thompson replied, > > > https://dspinellis.github.io/oral-history-of-unix/frs122/unixhist/finalhis.htm > > My summarization of the relevant paragraphs of Thompson's 1989 interview: > > After the PDP-7 was at the end of its life, they needed a new machine, > so > they proposed to buy a PDP-11 model that was about to be announced. The > proposal was rejected, but the psychology research department decided > to buy > it and give it to them. They placed the new PDP-11 in Osanna's office > next > to the PDP-7 and wrote cross tools. They wrote a PDP-11 assembler on > the 7 > in B and ran the paper tape across the floor to the 11. For its first > month, > the 11 was without a disk, so they had a fake in-memory filesystem. > Once it > was delivered, they got UNIX running on it in about a week and, at this > point, the topology of the directory structure was rather fixed. > > When the patent department was about to buy AstroText, a horrific and > expensive typesetting package, they instead produced a version of > nroff/troff for their specific formatting needs. They also talked the > patent > department into buying their system, i.e., the physical hardware, and > moving > it out. With that money, they bought an 11/45. Before the 11/45 was > available, they bought a PDP-11 that had PDP-10 memory management, > KS-1, a > one-of-a-kind machine. This was the first time they were using the > machine > at the same time for program development as typists. > > > https://dspinellis.github.io/oral-history-of-unix/mike/transcripts/thompson.htm > > Thalia > From tuhs at tuhs.org Fri Jan 16 17:12:19 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Fri, 16 Jan 2026 07:12:19 +0000 Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? In-Reply-To: References: Message-ID: On Jan 15, 2026, at 23:57, Ken Thompson wrote: > after the pdp-7, unix was ported to more > stock pdp-9 and pdp15 (both pdp7 upgrades) > > no pdp-10 at bell labs. Hi Ken, So the "PDP-10" that Mahoney refers to is the PDP-11 with KS-1 memory management? Seems like a strange machine. And did you only ever use the one PDP-7 from the graphics group, and the other PDP-9s and 15s were used by other groups? Warner Losh writes that the PDP-7 UNIX “Total install base was 4 (1 pdp-7, 2 pdp-9 and 1 pdp-15)”. https://papers.freebsd.org/2020/fosdem/losh-hidden_early_history_of_unix/ Thalia From tuhs at tuhs.org Fri Jan 16 19:20:09 2026 From: tuhs at tuhs.org (Ken Thompson via TUHS) Date: Fri, 16 Jan 2026 01:20:09 -0800 Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? In-Reply-To: References: Message-ID: except for porting and testing, i didnt use the pdp-9s or -15s. the pdp-7 could support 2 people while the others only had tty33. also the pdp-7 had the filesystem with all the current work. the ks-11 was the first memory protected pdp-11. we needed it to pretend like it was a real time sharing system. ks was the dec designation for a one-of-a-kind. dec did a lot of special system designs for customers. there is a computer, i think pdp-2, that was a completely custom built computer. On Thu, Jan 15, 2026 at 11:12 PM Thalia Archibald wrote: > On Jan 15, 2026, at 23:57, Ken Thompson wrote: > > after the pdp-7, unix was ported to more > > stock pdp-9 and pdp15 (both pdp7 upgrades) > > > > no pdp-10 at bell labs. > > Hi Ken, > > So the "PDP-10" that Mahoney refers to is the PDP-11 with KS-1 memory > management? Seems like a strange machine. > > And did you only ever use the one PDP-7 from the graphics group, and the > other > PDP-9s and 15s were used by other groups? Warner Losh writes that the > PDP-7 > UNIX “Total install base was 4 (1 pdp-7, 2 pdp-9 and 1 pdp-15)”. > > https://papers.freebsd.org/2020/fosdem/losh-hidden_early_history_of_unix/ > > Thalia > From tuhs at tuhs.org Fri Jan 16 23:51:44 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 16 Jan 2026 06:51:44 -0700 Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? In-Reply-To: References: Message-ID: On Fri, Jan 16, 2026 at 12:12 AM Thalia Archibald via TUHS wrote: > On Jan 15, 2026, at 23:57, Ken Thompson wrote: > > after the pdp-7, unix was ported to more > > stock pdp-9 and pdp15 (both pdp7 upgrades) > > > > no pdp-10 at bell labs. > > Hi Ken, > > So the "PDP-10" that Mahoney refers to is the PDP-11 with KS-1 memory > management? Seems like a strange machine. > > And did you only ever use the one PDP-7 from the graphics group, and the > other > PDP-9s and 15s were used by other groups? Warner Losh writes that the > PDP-7 > UNIX “Total install base was 4 (1 pdp-7, 2 pdp-9 and 1 pdp-15)”. > > https://papers.freebsd.org/2020/fosdem/losh-hidden_early_history_of_unix/ I wrote that because I found references, I think in the 0-edition manuals, that had those numbers. I got the impression from somewhere, and I can't quite find it this morning, that those machines were 'cast off' that the department used on an interim basis until they could get a pdp-11. But the evidence was thin at the time, and I included it because it was more than 0, which was a surprise to me. Warner From tuhs at tuhs.org Sat Jan 17 03:22:43 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 16 Jan 2026 12:22:43 -0500 Subject: [TUHS] RK disk, was UNIX v4 Source Code Commentary In-Reply-To: References: <5d2bf30c-1cb7-4356-8a59-a52871673c64@gmail.com> Message-ID: <20260116172244.1E0A0F16DFD5@ary.qy> It appears that Clem Cole via TUHS said: >Plus remember that V6 and V7 work fine and they do overlapped I/O also. In 1975 at Yale I brought up v5 or v6 at a PDP-11 we had. I distinctly recall that the RK11 driver was purely sequential because of controller hardware bugs that made overlapped seeks unreliable. I heard that they'd given up on a more sophsticated driver. We added a pair of RP20 20MB disk pack drives. The RP controller worked fine so one of the first things I did was to write an RP driver that sorted requests for each drive and did seek overlap. It made a difference, maybe 25% better throughput. R's, John From tuhs at tuhs.org Sat Jan 17 03:36:09 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Fri, 16 Jan 2026 12:36:09 -0500 Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? In-Reply-To: References: Message-ID: <202601161736.60GHa9c8045313@ultimate.com> Thalia Archibald wrote: > On Jan 15, 2026, at 23:57, Ken Thompson wrote: > > after the pdp-7, unix was ported to more > > stock pdp-9 and pdp15 (both pdp7 upgrades) > > > > no pdp-10 at bell labs. > So the "PDP-10" that Mahoney refers to is the PDP-11 with KS-1 memory > management? Seems like a strange machine. https://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option describes an MMU much like the KA10 (first PDP-10 CPU): Two sets of base and limit registers (highseg and lowseg). I think the second set of registers was an option on the KA (*). The PDP-10 was a follow-on for the PDP-6, which only had one base/limit pair. (*) Way WAY too much info for the TUHS list: The PDP-6, DEC's first machine larger than 18 bits had been regarded as an overreach for the then small company (only 23 were sold). Among other things it used large circuit boards that had to be soldered in, and the largest (core) memory box sold was 16K. One customer who wanted to run time sharing using only DEC memories returned the system because it was too flaky, but shops that bought larger memory boxes from 3rd parties had no problems. To get buy-in to making a follow-on to the '6, they went to ridiculous ends to make it possible to price the base system around $100,000 (the bare PDP-6 CPU listed at $176K) including making the following options: KE10 KA10 byte instruction option ("extended order code") KM10 KA10 16 Word 0.21 microsecond fast memory (ACs) option KP10 KA10 power fail/restart option [I/O Bus & 7 level PI?] KT10 KA10 single protection/relocation reg [never sold] KT10A KA10 dual protection/relocation regs Without "fast ACs", the registers (visible as the first 16 addresses) used external core (was also an option on the PDP-6). From tuhs at tuhs.org Sat Jan 17 04:00:06 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Fri, 16 Jan 2026 13:00:06 -0500 (EST) Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? Message-ID: <20260116180006.6E28E18C084@mercury.lcs.mit.edu> > From: Thalia Archibald > in Thompson's 1989 interview with Mahoney, he mentions that "Before the > 11/45 was available we bought a PDP-11 that had PDP-10 memory > management, KS-1, it was a one of a kind machine". In trying to find out more about the KS11: https://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option I queried Ken, and he was nice enough to reply, and explain to me that it operated like the memory management hardware on the KA10 model of the PDP-10. I think that's how the 'PDP-10' confusion started. > Does anyone know anything about this strange PDP-11 + KS-1? The KS11 was the very first hardware memory mangement available for the PDP-11. So, it was either that - or a bare macine (-11/20) with _no_ memory mangement. Bob Supnik told us a bit about the KS-11: "The KS11 created a PDP-10 (KA) style memory management system for the 11/20: that is, high-segment (instructions, in theory, and shareable, in theory) and low-segment (data)." No documentation on the KS11 has ever been located. There is KS11 emulation included in Bob's MIMIC PDP-11 simulator; in theory someone energetic could dig into that, and work out the details of how it works. More here: https://gunkies.org/wiki/Talk:KS11_Memory_Protection_and_Relocation_option if anyone is interested. MIMIC was written long ago (the header says "March 31, 1971"); it's in PDP-10 assembler (it long pre-dates SIMH), so it wouldn't be trivial. There was also support for the KS11 in UNIX V2, from which it would be easier to produce a programming manual for the thing. Alas, that version of UNIX has been lost (although a bit about how the KS11 worked can be deduced from the V2 manual, which is extant). > What was the model of PDP-11 first used for UNIX? The PDP-11/20. Dennis' "The Evolution of the Unix Time-sharing System": https://www.nokia.com/bell-labs/about/dennis-m-ritchie/hist.html indicates that they got it _very_ early in the life of the -11: "the PDP-11 was so new a product that no disk was available until December". A later comment there ("a single .5 MB disk") indicates that they probably got an RF11: https://gunkies.org/wiki/RF11_disk_controller Not sure why they didn't get an RC11. Noel From tuhs at tuhs.org Sat Jan 17 04:24:13 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Fri, 16 Jan 2026 13:24:13 -0500 Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? In-Reply-To: <202601161736.60GHa9c8045313@ultimate.com> References: <202601161736.60GHa9c8045313@ultimate.com> Message-ID: <202601161824.60GIODtE045992@ultimate.com> Another PDP-10 footnote, which brings things back around to Ken and UNIX: BB&N had done a VM LISP for the PDP-1, but wanted a larger, timeshared system with VM. They looked at the PDP-6 as ideal (a 36 bit word could hold two 18 bit pointers for the CAR and CDR of a LISP list element), but it was cancelled, but then they heard about development of the PDP-10. BB&N tried to interest DEC in building in hardware for paging, but as I previously noted, the DEC's emphasis at the time was NOT making another overblown white elephant; the 24-bit SDS 940 (the commercial version of the Berkeley modified SDS 930) had limited address space, so BB&N picked the PDP-10 and built their own external MMU (paging box). The project was led by Daniel Bobrow, and was named TENEX. PDP-10s were a major share of systems on the early ARPAnet, and most of them were running TENEX. Here's the cruicial bit of UNIX co-history: TENEX was designed in 1969 (and was up and running in under a year?), and took feedback from the Multics team on complicated stuff they should throw out, as well strong influences from the Berkeley "Genie" time sharing system; The term for a process in TENEX is "fork"). Ken had used the Berkeley system before joining the Multics team. (See DMR's "incomplete history of QED"(*)) In Ken's paper "Reflections on Trusting Trust" on the receipt of the Turing award, he wrote: I thank the ACM for this award. I can't help but feel that I am receiving this honor for timing and serendipity as much as technical merit. UNIX swept into popularity with an industry-wide change from central mainframes to autonomous minis. I suspect that Daniel Bobrow would be here instead of me if he could not afford a PDP-10 and had had to "settle" for a PDP-11 Dan Murphy (who had created TECO for the PDP-1 at MIT) who had worked on the TENEX VM system, and later went to DEC (first to port TENEX to the KI10, the second PDP-10 CPU, which BB&N again failed to convince DEC to implement their VM design in, but DID implement a much simpler paging system, using the same page size as TENEX) to turn TENEX into TOPS-20 has a page on TENEX, and whose reminiscences I have likely mis-remembered above: https://opost.com/tenex/ And includes a version of his history published by IEEE (in an issue that also includes an interview with Gordon Bell including some history of the PDP-6): https://opost.com/tenex/ahc_20150101_jan_2015.pdf And a longer version, written for a never-published book on PDP-10 history/lore, perhaps for the 1984 20th anniversary of the PDP-6? https://opost.com/tenex/hbook.html (*) https://www.nokia.com/bell-labs/about/dennis-m-ritchie/qed.html Ken wrote a version of QED for the MIT CTSS time sharing system on the 7090, that the Multics team was using for bootstrapping, then QED for Multics. From tuhs at tuhs.org Sat Jan 17 04:48:46 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 16 Jan 2026 18:48:46 +0000 Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? In-Reply-To: <20260116180006.6E28E18C084@mercury.lcs.mit.edu> References: <20260116180006.6E28E18C084@mercury.lcs.mit.edu> Message-ID: <4jBTjclcqijgZ5XYCOC-2gmh_sfCYHjy4vZfqWFPz7jZspJsazxiIyXs7dzNPmiKfHuPZndnaGjW9imak1kpxcRlqglnXroqBkRVdSqj6fc=@protonmail.com> On Friday, January 16th, 2026 at 10:00, Noel Chiappa via TUHS tuhs at tuhs.org wrote: > There was also support for the KS11 in UNIX V2, from which it would be easier > to produce a programming manual for the thing. Alas, that version of UNIX has > been lost (although a bit about how the KS11 worked can be deduced from the > V2 manual, which is extant). > > Noel I presume everything would be in the kernel that touches hardware memory management stuff? Reason I ask is there is plenty of documented EAE use in V2 userland stuff: https://gitlab.com/segaloco/v2src For those who haven't perused it, thats my slow-burn restoration of the V2 userland from Dennis Ritchie's "s2-bits" tape. EAE use dates it to the PDP-11/20 system and presence of no, V1, and V2 a.out magic numbers puts them at V2. By comparison, the V2 "cmd" path on the UNIX tree (s1-bits recovery) is later versions, probably V3, as they are still assembler but any EAE usage has been replaced with PDP-11/45 arithmetic operations. If there is any compelling thought on whether any V2 userland code would *know* about this memory subsystem, I'm happy to go disassembling and looking around for clues. We don't know of any other V2/V3 artifacts beyond manuals and s1/s2 bits tapes do we? - Matt G. From tuhs at tuhs.org Sat Jan 17 04:53:57 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Fri, 16 Jan 2026 10:53:57 -0800 Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? In-Reply-To: <202601161824.60GIODtE045992@ultimate.com> References: <202601161736.60GHa9c8045313@ultimate.com> <202601161824.60GIODtE045992@ultimate.com> Message-ID: <26636f72-24a6-3ae8-6a17-89f3e05504e0@bitsavers.org> On 1/16/26 10:24 AM, Phil Budne via TUHS wrote: > Ken wrote a version of QED for the MIT CTSS time sharing system on the > 7090, that the Multics team was using for bootstrapping, then QED for > Multics. > The 1965 manual for Genie QED http://bitsavers.org/pdf/sds/9xx/940/ucbProjectGenie/30.60.30_QED_Nov65.pdf From tuhs at tuhs.org Sat Jan 17 04:56:04 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Fri, 16 Jan 2026 10:56:04 -0800 Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? In-Reply-To: <20260116180006.6E28E18C084@mercury.lcs.mit.edu> References: <20260116180006.6E28E18C084@mercury.lcs.mit.edu> Message-ID: On 1/16/26 10:00 AM, Noel Chiappa via TUHS wrote: > Bob Supnik told us a bit about the KS-11: "The KS11 created a PDP-10 (KA) > style memory management system for the 11/20: that is, high-segment > (instructions, in theory, and shareable, in theory) and low-segment (data)." > > No documentation on the KS11 has ever been located. There is KS11 emulation > included in Bob's MIMIC PDP-11 simulator; in theory someone energetic could > dig into that, and work out the details of how it works. More here: > > I thought someone had the segmented kernel running in SIMH, which is why the KS11 support was added. From tuhs at tuhs.org Sat Jan 17 05:23:33 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Fri, 16 Jan 2026 14:23:33 -0500 (EST) Subject: [TUHS] A PDP-10 used for UNIX just after the PDP-7? Message-ID: <20260116192333.A83F818C082@mercury.lcs.mit.edu> > From: Matt G. > I presume everything would be in the kernel that touches hardware > memory management stuff? I expect so. We know from Dennis' "A hardware story": https://www.nokia.com/bell-labs/about/dennis-m-ritchie/odd.html that the KS11 took almost everything in the I/O space on the UNIBUS out of the user's address space. The I/O space was where the KS11 registers were. So, any fooling with the memory management by the user would have to have been done by a system call - hopefully documented in the V2 manual, which we have. I do't see any such system call (although break() may have played with it). Noel From tuhs at tuhs.org Sat Jan 17 06:26:56 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Fri, 16 Jan 2026 15:26:56 -0500 (EST) Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available Message-ID: <20260116202656.8853518C082@mercury.lcs.mit.edu> > From: Briam Rodriguez > From: Angelo Papenhoff >> The v4 RK11 driver does not work with simh emulation correctly when >> using multiple disks. I've had to use the v5 driver > My theory: SIMH isn't correctly emulating the behavior when multiple > seeks complete at the same (or nearly the same) simulated time. You're probably right, but let me throw one additional bit of potentially applicable data onto the pile. There are actually at least two different RK11 controllers: the RK11-D (four quad boards), and the RK11-C: https://gunkies.org/wiki/RK11-C_disk_controller implemented with a bunch of smaller 'FLIP CHIP's (see image). They are _mostly_ program compatible, _but_ it's _possible_ that the V4 driver uses something that works on the RK11-C but not on the RK11-D (which could be why the V5 driver was changed from the V4 one). If there is such a difference, I have no idea which SIMH. implements. Your suggestion to "instrumenting[] rkintr() to log the rkcs and rkds values on each interrupt" sounds like a good way to go. I said "at least two" because there are strong clues that there was yet another, earlier version: https://gunkies.org/wiki/RK11_disk_controller#Early_RK11_version but I doubt that's relevant here. Noel From tuhs at tuhs.org Sat Jan 17 08:06:54 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 16 Jan 2026 22:06:54 +0000 Subject: [TUHS] Possible Assembly UNIX Kernel Images (s1-bits cunix/wunix)? Message-ID: Hello everyone, I've been picking back up on some of my V2/V3 era reverse engineering efforts, picking through stuff from the Dennis_Tapes archive, and I came across something I don't think I've seen discussed. On the s1 tape, which we've yoinked a lot of V3 userland sources from, there are files cunix and wunix. Upon some disassembly and inspection, I believe these may be assembly UNIX kernels, although I haven't dug around too much to see what version they match most closely. Here are some findings that support my suspicions: - Both files begin with a 407 magic number, making them V2 a.out binaries. - Both begin with a branch that jumps over a few things then calls a subroutine. That subroutine matches "copyz" from u3.s in the scanned V1 kernel description from BTL. Indeed this jump in that kernel is also to copyz. Of course, this is only the first few bits executed, but I would be surprised to find such a close match elsewhere in the system. I do this sort of analysis on old video game code all the time, so I feel pretty confident in identifying these as possible assembly-era kernels. Anyone dug around in these before? These should be PDP-11/20 kernels as I'm finding plenty of EAE references, just like the s2-bits V2 binaries. What I'm hoping to find here are bits that might indicate KS11 support, what with the recent chit chat about KS11 in the V2 kernel. - Matt G. From tuhs at tuhs.org Sat Jan 17 08:11:11 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Fri, 16 Jan 2026 17:11:11 -0500 Subject: [TUHS] Possible Assembly UNIX Kernel Images (s1-bits cunix/wunix)? In-Reply-To: References: Message-ID: Hi Matt, Saw your post about the v2src restoration project. I took a crack at disassembling the remaining binaries from the s2-bits tape - specifically the bin/ directory utilities. I've got 26 commands disassembled and formatted to match your existing style conventions: as, bas, cc, db, dc, ds, du, ed, fc, find, form, ld, maki, mv, nm, od, pr, roff, size, sort, stat, tap, tm, un, wc, who They're ready as a patch file. Please find it attached. I tried creating a PR on gitlab but it wouldn't let me due to auth issues. Happy to help with more disassembly work if there are other artifacts worth looking at. -- Briam R. On 1/16/26 5:06 PM, segaloco via TUHS wrote: > Hello everyone, I've been picking back up on some of my V2/V3 era > reverse engineering efforts, picking through stuff from the Dennis_Tapes > archive, and I came across something I don't think I've seen discussed. > > On the s1 tape, which we've yoinked a lot of V3 userland sources from, > there are files cunix and wunix. Upon some disassembly and inspection, > I believe these may be assembly UNIX kernels, although I haven't dug > around too much to see what version they match most closely. Here are > some findings that support my suspicions: > > - Both files begin with a 407 magic number, making them V2 a.out > binaries. > - Both begin with a branch that jumps over a few things then calls a > subroutine. That subroutine matches "copyz" from u3.s in the scanned > V1 kernel description from BTL. Indeed this jump in that kernel is also > to copyz. > > Of course, this is only the first few bits executed, but I would be > surprised to find such a close match elsewhere in the system. I do this > sort of analysis on old video game code all the time, so I feel pretty > confident in identifying these as possible assembly-era kernels. > > Anyone dug around in these before? These should be PDP-11/20 kernels as > I'm finding plenty of EAE references, just like the s2-bits V2 binaries. > What I'm hoping to find here are bits that might indicate KS11 support, > what with the recent chit chat about KS11 in the V2 kernel. > > - Matt G. -------------- next part -------------- From 2498b221d611cd131f6be10610f55e21fb136c40 Mon Sep 17 00:00:00 2001 From: Briam Rodriguez Date: Fri, 16 Jan 2026 16:59:29 -0500 Subject: [PATCH] add disassembled bin/ commands from s2-bits --- cmd/as.s | 817 ++++++++++++++++++++ cmd/bas.s | 2106 ++++++++++++++++++++++++++++++++++++++++++++++++++++ cmd/cc.s | 871 ++++++++++++++++++++++ cmd/db.s | 793 ++++++++++++++++++++ cmd/dc.s | 508 +++++++++++++ cmd/ds.s | 267 +++++++ cmd/du.s | 187 +++++ cmd/ed.s | 437 +++++++++++ cmd/fc.s | 309 ++++++++ cmd/find.s | 140 ++++ cmd/form.s | 300 ++++++++ cmd/ld.s | 878 ++++++++++++++++++++++ cmd/maki.s | 68 ++ cmd/mv.s | 157 ++++ cmd/nm.s | 211 ++++++ cmd/od.s | 112 +++ cmd/pr.s | 342 +++++++++ cmd/roff.s | 1025 +++++++++++++++++++++++++ cmd/size.s | 762 +++++++++++++++++++ cmd/sort.s | 265 +++++++ cmd/stat.s | 298 ++++++++ cmd/tap.s | 666 +++++++++++++++++ cmd/tm.s | 284 +++++++ cmd/un.s | 79 ++ cmd/wc.s | 180 +++++ cmd/who.s | 150 ++++ 26 files changed, 12212 insertions(+) create mode 100644 cmd/as.s create mode 100644 cmd/bas.s create mode 100644 cmd/cc.s create mode 100644 cmd/db.s create mode 100644 cmd/dc.s create mode 100644 cmd/ds.s create mode 100644 cmd/du.s create mode 100644 cmd/ed.s create mode 100644 cmd/fc.s create mode 100644 cmd/find.s create mode 100644 cmd/form.s create mode 100644 cmd/ld.s create mode 100644 cmd/maki.s create mode 100644 cmd/mv.s create mode 100644 cmd/nm.s create mode 100644 cmd/od.s create mode 100644 cmd/pr.s create mode 100644 cmd/roff.s create mode 100644 cmd/size.s create mode 100644 cmd/sort.s create mode 100644 cmd/stat.s create mode 100644 cmd/tap.s create mode 100644 cmd/tm.s create mode 100644 cmd/un.s create mode 100644 cmd/wc.s create mode 100644 cmd/who.s diff --git a/cmd/as.s b/cmd/as.s new file mode 100644 index 0000000..658a14f --- /dev/null +++ b/cmd/as.s @@ -0,0 +1,817 @@ +/ as -- assembler pass 1 + + br start +tsize: mov 0(sp),(sp) + 0 + 0 + 0 + 0 +symend: 1 + +/ start of program +start: + jmp main + +/ error handling +error: + jsr pc,pass1 + movb errflg,r0 + sys creat; tmpf1; 1000 + movb errflg,r0 + sys creat; tmpf2; 0 + movb passno,r0 + tstb dotflg + bne 1f + jsr r5,errstr + <-e\n\0>; .even + inc (r1) + bic $1,(r1)+ + inc (r1) + bic $1,(r1)+ + inc (r1) + bic $1,(r1)+ + mov r0,r1 + sys creat; tmpf1; 1000 + 0 + rtt + +/ setup temporary file name +tmpset: + mov r4,-(sp) + mov (r5)+,r4 + mov r4,0f + clr r0 +1: + tstb (r4)+ + beq 1f + inc r0 + br 1b +1: + mov r0,0f+2 + mov $1,r0 + sys creat; 0:..; 0 + +/ return from tmpset + mov r5,0f + mov $1,r0 + sys creat; 0:..; rtt + +1: + incb 11.(r4) + cmpb 11.(r4),$'z + blos 1b + mov 0b,0f + jsr r5,tmpset; 0:..; clr @syms+2 + incb dotflg + mov r0,-(sp) + mov r1,-(sp) + mov (r5)+,r0 + mov @argptr,0f + beq 1f + clr @argptr + mov r0,-(sp) + jsr r5,tmpset; 0:..; rtt +1: + mov (sp)+,r0 + mov argptr,0f + movb r0,0f+48. + mov $tmpstr,r0 + mov $-4,r1 + clr hession + mov $12.,hession+2 + add $48.,hession + movb hession,-(r0) + inc r1 + bne 1b + mov $1,r0 + sys creat; tmpstr; 7 + mov (sp)+,r1 + mov (sp)+,r0 + rts r5 + +tmpstr: < xxxx\n\0> + .even + +/ range check +rangck: + cmp r0,$9. + bhi 1f + rts pc +1: + jsr r5,errstr; + .even + +clrone: + clr r0 + rts pc + +/ skip to newline/semicolon/eof +skip: + cmp r4,$'\n + beq 1f + cmp r4,$'; + beq 1f + cmp r4,$4 + beq 1f + rts pc +1: + add $2,(sp) + rts pc + +/ symbol table routines +lookup: + mov r2,-(sp) + mov r3,-(sp) + mov $2,r5 + mov $symtab,r2 + clr -(sp) + jsr pc,gethash + mov r3,hession + mov $40.,hession+2 + jsr pc,gethash + add r3,hession + mov $40.,hession+2 + jsr pc,gethash + add hession,r3 + add r3,(sp) + mov r3,(r2)+ + dec r5 + bne 1b + jsr pc,gethash + mov r3,hession + add r3,(sp) + mov $12.,hession+4 + mov hession,(r2) + jsr pc,gethash + tst r3 + bne 1b + mov (sp)+,hession + clr hession+2 + mov $1000.,hession+8 + mov hession,r0 + asl r0 + add $symtab,r0 + cmp r0,$symtab + bhi 1f + mov $symend,r0 +1: + mov $symtab,r2 + mov -(r0),r4 + beq 1f + cmp (r2)+,(r4)+ + bne 1b + cmp (r2)+,(r4)+ + bne 1b + cmpb 1(r4),1(r2) + bne 1b + br 2f +1: + mov hession+4,r4 + mov r4,(r0) + mov r4,-(sp) + add $16.,r4 + cmp r4,0f + blos 1f + add $512.,0f + sys intr; symtab+2 + mov (sp)+,r4 + mov (r2)+,(r4)+ + mov (r2)+,(r4)+ + mov (r2)+,(r4)+ + clr (r4)+ + mov r4,hession+4 + sub $4,r4 +2: + mov r4,-(sp) + sub $symhash,r4 + asr r4 + jsr pc,putw + mov (sp)+,r4 + mov (sp)+,r3 + mov (sp)+,r2 + tst (sp)+ + rts pc + +/ get hash value +gethash: + jsr pc,rch + movb spts(r0),r3 + ble 1f + rts pc +1: + movb r0,savec + clr r3 + rts pc + +/ read character +rch: + movb savec,r0 + beq 1f + clrb savec + rts pc +1: + dec ibufcnt + blt fillbuf + movb @ibufp,r0 + inc ibufp + bic $177600,r0 + bne 1b + rts pc + +/ fill input buffer +fillbuf: + movb infile,r0 + beq nextfile + sys read; ibuf; 512. + bes 1f + tst r0 + beq 1f + mov r0,ibufcnt + mov $ibuf,ibufp + br rch +1: + movb infile,r0 + clrb infile + sys creat; tmpf1; 1000 + +nextfile: + decb fcount + bgt 1f + mov $4,r0 + rts pc +1: + tst pass + beq 1f + jsr r5,errstr; + .even + jmp error+8 +1: + mov argptr,r0 + tst (r0)+ + mov (r0),0f + mov r0,argptr + incb fnumba + sys open; 0:..; 0 + + bec 1f + clr @0b + jmp error+8 +1: + movb r0,infile + mov $1,line + mov r4,-(sp) + mov r1,-(sp) + mov $5,r4 + jsr pc,putw + mov @argptr,r1 + movb (r1)+,r4 + beq 1f + jsr pc,putw + br 1b +1: + mov $-1,r4 + jsr pc,putw + mov (sp)+,r1 + mov (sp)+,r4 + br rch + +/ get token +readop: + mov tok,r4 + beq 1f + clr tok + rts pc +1: + jsr pc,1f + jsr pc,putw + rts pc + +1: + jsr pc,rch + mov r0,r4 + movb spts(r0),r1 + bgt 1f + jmp @dtbl(r1) + +/ dispatch table for token types +dtbl: + dtbl+2 + aletter + anumber + asquote + adquote + dtbl+2 + adoll + aslash + aless + dtbl+2 + aesc + +/ escape sequences +aesc: + jsr r5,errstr; ; .even + +/ operator table entry +optbl: + <+-*/%&|>>>!<^^~\0> + .even + +aslash: + jsr pc,rch + mov r0,r4 + cmp r0,$4 + beq 1f + cmp r0,$'\n + bne aslash +1: + rts pc + +/ letter - identifier +aletter: + movb r0,savec + cmp r1,$32. + ble 1f + cmp r1,$45. + blt 1f + jmp lookup +1: + jsr pc,readnum + br 2f + +/ number +anumber: + jsr pc,rch + mov r0,r4 + movb spts(r0),r1 + bgt 1f + cmp r0,$'b + beq bref + cmp r0,$'f + beq fref + cmp r0,$'. + bne 1f + mov hession,r1 + clr r0 +1: + movb r0,savec + mov r1,r0 + mov (sp)+,r3 + mov (sp)+,r2 + rts pc + +/ backref (Nb) +bref: + mov r0,r3 + mov hession,r0 + jsr pc,rangck + add $'a,r0 + cmp r3,$'b + beq 1f + add $12.,r0 +1: + mov r0,r4 + mov (sp)+,r3 + mov (sp)+,r2 + add $2,(sp) + rts pc + +/ forward ref (Nf) +fref: + jsr pc,rch + mov r0,r4 + cmp r0,$4 + beq 1f + cmp r0,$'\n + bne fref +1: + rts pc + +/ dollar sign (immediate) +adoll: + jsr r5,errstr; + .even + +/ less-than (string) +aless: + mov $'<,r4 + jsr pc,putw + clr val + jsr pc,getch + tst r1 + bne 1f + mov r0,r4 + bis $400,r4 + jsr pc,putw + inc val + br 1b +1: + mov $-1,r4 + jsr pc,putw + mov $'<,r4 + tst (sp)+ + rts pc + +/ get string char +getch: + jsr pc,rch + cmp r0,$4 + beq 1f + cmp r0,$'\n + beq 1f + clr r1 + cmp r0,$'\\ + bne 2f + jsr pc,rch + mov $esctbl,r2 +1: + cmpb (r2)+,r0 + beq 3f + tstb (r2)+ + bpl 1b + rts pc +3: + movb (r2)+,r0 + clr r1 + rts pc +2: + cmp r0,$'> + bne 4f + inc r1 +4: + rts pc + +esctbl: + 'n; 12 + 'r; 15 + 't; 11 + 'b; 10 + '0; 0 + -1 + +/ read number +readnum: + mov r2,-(sp) + mov r3,-(sp) + clr r1 + clr hession + jsr pc,rch + jsr r5,rangck + $'0 + $'9 + br 1f + +1: + sub $'0,r0 + mov $12.,hession+2 + add r0,hession + asl r1 + asl r1 + asl r1 + add r0,r1 + br readnum+6 + +/ expression parser +expr: + cmp r0,$'b + beq bref + cmp r0,$'f + beq fref + cmp r0,$'. + bne 1f + mov hession,r1 + clr r0 +1: + movb r0,savec + mov r1,r0 + mov (sp)+,r3 + mov (sp)+,r2 + rts pc + +/ expression with operators +exprop: + jsr pc,rch + mov r0,r4 + cmp r0,$'< + bne 1f + jmp aless +1: + jsr pc,oprand + add $2,dotval + rts pc + +/ addressing mode parsing +opclass: + mov r0,-(sp) + jsr pc,readop + mov (sp)+,r0 + asl r0 + jmp @clstbl(r0) + +clstbl: + sngop + dblop + sngop + dblop + dblop + sngop + sngop + sngop + sngop + sngop + sngop + branch + branch + extjsr + extsob + branch + branch + branch + branch + branch + branch + branch + branch + sngop + fltop + fltop + fltop + fltop + sngop + branch + +/ single operand instruction +sngop: + jsr pc,oprand + cmp r4,$', + bne 1f + jsr pc,readop + jsr pc,oprand + add $2,dotval +1: + rts pc + +/ double operand instruction +dblop: + jsr pc,oprand + jsr pc,readop + jsr pc,oprand + add $2,dotval + cmp r4,$', + bne 1f + jsr pc,readop + br dblop+4 +1: + rts pc + +/ branch instruction +branch: + jsr pc,oprand + inc dotval + bic $1,dotval + rts pc + +/ floating point operation +fltop: + jsr pc,oprand + tst r3 + bne 1f + jsr r5,errstr; + .even +1: + tst r2 + bne 1f + inc pass +1: + rts pc + +/ register expression +regxpr: + cmp r4,$200 + bcs 1f + bisb $40,(r4) + jsr pc,readop + cmp r4,$', + bne 1f + jsr pc,readop + br regxpr +1: + rts pc + +/ segment switching +segswt: + mov dotval,r1 + asl r1 + mov dotval,locseg(r1) + mov absdat(r0),dotval + asr r0 + sub $23.,r0 + mov r0,dotrel + rts pc + +/ operand parsing +oprand: + cmp r4,$200 + bcs 1f + mov $40,(r4) + jsr pc,readop + cmp r4,$', + bne 1f + jsr pc,readop + jsr pc,oprand + rts pc +1: + jsr r5,errstr; + .even + jmp error+8 + +/ extended JSR +extjsr: + cmp r4,$', + beq 1f + jsr pc,oprand + rts pc +1: + jsr pc,readop + jsr pc,oprand + rts pc + +/ extended SOB +extsob: + jsr pc,oprand + inc dotval + bic $1,dotval + rts pc + +/ pass 1 driver +pass1: + jsr pc,pass1dr + rts pc + +pass1dr: + jsr pc,readop + cmp r4,$'\n + beq 1f + cmp r4,$'; + beq 1f + cmp r4,$4 + bne pass1dr +1: + jmp pass1+8 + +/ put word to output +putw: + tst pass + bne 1f + cmp r4,$'\n + beq 1f + movb r4, at bufp + inc bufp + cmp bufp,$bufend + bcs 1f + mov $buf,bufp + movb errflg,r0 + sys creat; tmpf1; 1000 + +1: + rts pc + +/ error message output +errstr: + mov r4,-(sp) + mov (r5)+,r4 + mov r4,0f + mov $tmpstr,r0 + mov $1,r0 + sys write; 0:..; 4 + + mov (sp)+,r4 + br skip + +/ main entry point +main: + sys intr; error + bic r1,-(sp) + mov sp,r5 + mov (r5)+,r0 + cmpb @2(r5),$'- + bne 1f + tst (r5)+ + dec r0 + br main+16. +1: + clr oteflag + movb r0,fcount + mov r5,argptr + jsr r5,tmpset + ; .even + movb r0,errflg + jsr r5,tmpset + ; .even + movb r0,passno + jsr pc,setup + mov $1,r0 + sys creat; tmpf1; 2 + + jmp error+8 + +/ setup symbol table +setup: + mov $symtbl,r1 + mov $symtab,r0 +1: + mov (r1)+,(r0)+ + beq 1f + mov (r1)+,(r0)+ + mov (r1)+,r2 + bic $37,r2 + mov r2,(r0)+ + mov r1,-(sp) + jsr pc,hshlkp + mov (sp)+,r1 + mov r1,(r0) + sub $6,(r0) + tst (r1)+ + br 1b +1: + rts pc + +/ hash lookup +hshlkp: + mov topstk,r1 + add topstk+2,r1 + add topstk+4,r1 + mov r1,hession + clr hession+2 + mov $1000.,hession+8 + mov hession,r0 + asl r0 + add $symtab,r0 + cmp r0,$symtab + bhi 1f + mov $symend,r0 +1: + mov -(r0),r2 + beq 1f + mov $symtab,r3 + cmp (r2)+,(r3)+ + bne 1b + cmp (r2)+,(r3)+ + bne 1b + mov (r2)+,r1 + bic $37,r1 + cmp r1,(r3)+ + bne 1b +1: + rts pc + +/ instruction table (partial) +/ format: name; opcode; type +symtbl: +.=.+2 +locseg: .=.+24. +absdat: .=.+24. +/ EAE registers +div = 177300 +ac = 177302 +mq = 177304 +mul = 177306 +sc = 177310 +sr = 177311 +nor = 177312 +lsh = 177314 +ash = 177316 + +/ temp file names +tmpf1: +tmpf2: +tmpf3: + +/ data area +.bss +savec: .=.+1 +dotflg: .=.+1 +fnumba: .=.+1 +errflg: .=.+1 +passno: .=.+1 +infile: .=.+1 +fcount: .=.+1 + .even +line: .=.+2 +pass: .=.+2 +tok: .=.+2 +val: .=.+2 +dotval: .=.+2 +dotrel: .=.+2 +oteflag: .=.+2 +argptr: .=.+2 +ibufcnt: .=.+2 +ibufp: .=.+2 +bufp: .=.+2 +topstk: .=.+6 +hession: .=.+12. +ibuf: .=.+512. +buf: .=.+512. +bufend: +symhash: .=.+2048. +symtab: .=.+4096. +syms: diff --git a/cmd/bas.s b/cmd/bas.s new file mode 100644 index 0000000..a96409e --- /dev/null +++ b/cmd/bas.s @@ -0,0 +1,2106 @@ +/ bas -- BASIC interpreter + + br start + mov @(r4)+,-(r2) + 0 + 0 + + bgt 1f + 0 + +start: + jmp init + +/ return from FPU trap +fpret: + rts r5 + +/ save state for FPU trap handler +fptrap: + mov (sp)+,fppc + mov (sp)+,fpps + mov r0,fpr0 + mov $fpregs,r0 + mov r1,(r0)+ + mov r2,(r0)+ + mov r3,(r0)+ + mov r4,(r0)+ + mov r5,(r0)+ + mov sp,(r0)+ + sub $10,sp + mov (r0),r5 + clr fperr + bic $100000,fpflags + mov -(r5),r5 + mov r5,r4 + bic $7777,r4 + cmp r4,$170000 + bne fpbad + bic $170000,r5 + mov r5,r4 + bit $7000,r4 + bne 1f + bit $700,r4 + bne 2f + cmp r4,$12 + bhi fpbad + asl r4 + jmp @fptbl(r4) + +fptbl: + fpop0; fpop1 + fpop2; fpop3; fpop3 + fpop3; fpop3; fpop3 + fpop4; fpop5 + +2: + cmp r5,$400 + bge 3f + jsr r1,fpaddr + .+4 + .+2 + br 4f + +3: + jsr r1,fpaddr + .+4 + .+2 +4: + mov r3,r5 + asl r4 + asl r4 + clrb r4 + swab r4 + asl r4 + jsr pc, at fptbl2(r4) + br fpdone + +fptbl2: + fpop3; fpld + fpst; fpop3; fpneg + fpabs; fpclr; fpadd + fpsub; fpmul; fpdiv + fpcmp; fpmod; fpldx + fpstx; fpint; fpldc + fpldi; fpstc; fpsti + +1: + cmp r5,$5000 + blt fpop6 + mov r5,r2 + clrb r2 + cmp r2,$6400 + blt 1f + sub $1400,r2 +1: + cmp r2,$5000 + bne 2f + jsr r1,fpaddr + .+4 + .+2 + br 3f + +2: + cmp r2,$5400 + bne 4f + jsr r1,fpaddr + .+6; .+4 + br 3f + +4: + jsr r1,fpaddr + .+4 + .+2 +3: + jsr pc,getfreg + mov r2,r5 + clrb r4 + swab r4 + asl r4 + jsr pc, at fptbl3(r4) + br fpdone + +fptbl3: + fpop3; fpop3 + fpmulf; fpmuld + fpaddf; fpaddd + fpldf; fpstf + fpsubf; fpsubd + fpdivf; fpdivd + fpcmpf; fpcmpd + fpmodf; fpmodd + fpldfx; fpstfx + fpaddx; fpsubx + fpldcx; fpstcx + +fpbad: + inc fperr + br fpret2 + +fpop0: + mov fpflags,r0 + bic $177760,r0 + mov r0,fpps + br fpret2 + +fpop1: + bic $200,fpflags + br fpret2 + +fpop2: + bis $200,fpflags + br fpret2 + +fpop3: + bic $100,fpflags + br fpret2 + +fpop4: + bis $100,fpflags + br fpret2 + +fpdone: + mov $fpregs+8.,r0 + bic $17,(r0) + tst (r5) + bpl 1f + bis $10,(r0) + br fpret2 +1: + bne fpret2 + bis $4,(r0) +fpret2: + mov $fpregs,r0 + mov (r0)+,r1 + mov (r0)+,r2 + mov (r0)+,r3 + mov (r0)+,r4 + mov (r0)+,r5 + mov (r0)+,sp + mov fpr0,r0 + mov fpps,-(sp) + mov fppc,-(sp) + tst fperr + bne 1f + rti +1: + mov @$14,pc + +/ get FPU register address +getfreg: + mov r5,r3 + bic $177770,r3 + asl r3 + add $fpregs+8.,r3 + mov r5,r0 + bic $177707,r0 + asr r0 + asr r0 + jmp @fprtbl(r0) + +fprtbl: + 1f; 2f; 3f; 4f + 5f; 6f; 7f; 8f + +1: + jmp (r1)+ + +2: + sub $fpregs+8.,r3 + cmp r3,$14 + bcc fpbad + asl r3 + asl r3 + add $fpac,r3 + tst (r1)+ + rts r1 + +3: + bit $100,fpflags + bne fpbad + cmp r3,$fpregs+12. + bcc fpbad + tst (r1)+ + rts r1 + +4: + cmp r3,$fpregs+14. + beq fpbad + mov (r3),r3 + br fpchk + +5: + mov (r3),-(sp) + jsr pc, at 2(r1) + add r0,(r3) + mov (sp)+,r3 + br fpchk + +6: + mov @0(r3),-(sp) + add $2,(r3) + mov (sp)+,r3 + br fpchk + +7: + cmp r3,$fpregs+14. + beq fpbad + jsr pc, at 2(r1) + sub r0,(r3) + mov (r3),r3 + br fpchk + +8: + cmp r3,$fpregs+14. + beq fpbad + sub $2,(r3) + mov @0(r3),r3 + br fpchk + +fpop5: + mov @fppc,-(sp) + add $2,fppc + add (r3),(sp) + mov (sp)+,r3 + br fpchk + +fpop6: + jsr r1,fpop5 + 0 + 0 + mov (r3),r3 + br fpchk+2 + +fpchk: + bit $1,r3 + bne fpbad + cmp r3,$40010 + bcs fpbad + cmp r3,$57770 + bcc fpbad + add $4,r1 + rts r1 + +/ load float to internal format +fpld: + mov $fpwork,r0 + jsr pc,1f + mov r3,r2 + mov $fpwork2,r0 +1: + clr (r0) + mov (r2)+,r1 + mov r1,-(sp) + beq 2f + blt 3f + inc (r0)+ + br 4f +3: + dec (r0)+ +4: + bic $177600,r1 + bis $200,r1 + br 5f +2: + clr (r0)+ +5: + mov r1,(r0)+ + mov (r2)+,(r0)+ + bit $200,fpflags + beq 1f + mov (r2)+,(r0)+ + mov (r2)+,(r0)+ + br 2f +1: + clr (r0)+ + clr (r0)+ +2: + mov (sp)+,r1 + asl r1 + clrb r1 + swab r1 + sub $200,r1 + mov r1,(r0)+ + rts pc + +/ store from internal to external format +fpst: + mov $fpwork+2,r0 + mov (r0)+,r1 + mov r1,-(sp) + mov (r0)+,r2 + bis r2,(sp) + mov (r0)+,r3 + bis r3,(sp) + mov (r0)+,r4 + bis r4,(sp)+ + bne 1f + clr fpwork + rts pc +1: + bit $177400,r1 + beq 2f + clc + ror r1 + ror r2 + ror r3 + ror r4 + inc (r0) + br 1b +2: + bit $200,r1 + bne 1f + asl r4 + rol r3 + rol r2 + rol r1 + dec (r0) + br 2b +1: + mov r4,-(r0) + mov r3,-(r0) + mov r2,-(r0) + mov r1,-(r0) + rts pc + +/ copy float r3 -> r2 +fpcpy32: + mov (r3)+,(r2)+ + mov (r3)+,(r2)+ + bit $200,fpflags + beq 1f + mov (r3)+,(r2)+ + mov (r3)+,(r2)+ + rts pc +1: + clr (r2)+ + clr (r2)+ + rts pc + +/ copy float r2 -> r3 +fpcpy23: + mov (r2)+,(r3)+ + mov (r2)+,(r3)+ + bit $200,fpflags + beq 1f + mov (r2)+,(r3)+ + mov (r2)+,(r3)+ +1: + rts pc + +/ clear float at r3 +fpclr: + clr (r3)+ + clr (r3)+ + bit $200,fpflags + beq 1f + clr (r3)+ + clr (r3)+ +1: + rts pc + +/ negate float at r3 +fpneg: + tst (r3) + beq 1f + add $100000,(r3) +1: + rts pc + +/ absolute value at r3 +fpabs: + bic $100000,(r3) + rts pc + +/ nop +fpnop: + rts pc + +/ compare floats +fpcmp: + mov $fpwork+2,r5 + cmp (r2)+,(r3)+ + bgt 1f + blt 2f + cmp (r2)+,(r3)+ + bne 3f + bit $200,fpflags + beq 4f + cmp (r2)+,(r3)+ + bne 3f + cmp (r2)+,(r3)+ + beq 4f +3: + bhi 1f +2: + mov $1,(r5) + rts pc +1: + mov $-1,(r5) + rts pc +4: + clr (r5) + rts pc + +/ copy r3 -> r2 (single precision mode) +fpldf: + mov (r3)+,(r2)+ + mov (r3)+,(r2)+ + bit $200,fpflags + bne 1f + mov (r3)+,(r2)+ + mov (r3)+,(r2)+ + rts pc +1: + clr (r2)+ + clr (r2)+ + rts pc + +/ copy r2 -> r3 (single precision mode) +fpstf: + mov (r2)+,(r3)+ + mov (r2)+,(r3)+ + bit $200,fpflags + bne 1f + clr (r3)+ + clr (r3)+ +1: + rts pc + +/ load integer to float +fpldi: + mov $fpwork,r0 + mov $1,(r0)+ + mov (r3)+,(r0)+ + bit $100,fpflags + beq 1f + mov (r3)+,(r0)+ + clr (r0)+ + clr (r0)+ + mov $30,(r0)+ + jmp fpst+4 +1: + clr (r0)+ + clr (r0)+ + clr (r0)+ + mov $10,(r0) + jmp fpst+4 + +/ store float to integer +fpsti: + mov r3,r5 + mov $fpwork,r0 + jsr pc,fpld+4 + mov $fpwork+2,r0 + mov (r0)+,r1 + mov (r0)+,r2 + mov (r0)+,r3 + mov fpwork2+8.,r0 + cmp r0,$50 + bge 1f + clc + ror r1 + ror r2 + ror r3 + inc r0 + br .-14 +1: + bgt 2f + tst r1 + bne 2f + bit $100,fpflags + beq 3f + tst fpwork + bge 4f + neg r3 + adc r2 + bcs 4f + neg r2 +4: + mov r2,(r5) + mov r3,2(r5) + rts pc +3: + tst r2 + bne 2f + tst fpwork + bge 5f + neg r3 +5: + mov r3,(r5) + rts pc +2: + bis $1,fpflags + jmp fpret2 + +/ floating point add setup +fpadd: + mov $fpwork,r0 + jsr pc,fpld+4 + mov (r3),fpwork2+8. + jsr pc,fpadd2 + jmp fpdone + +/ floating point subtract +fpsub: + mov $fpwork,r0 + jsr pc,fpld+4 + mov fpwork2+8.,(r3) + mov r3,r5 + jmp fpdone + +/ modify status flags +fpmod: + mov (r3),fpflags + jmp fpret2 + +/ read status flags +fpmodx: + mov fpflags,(r3) + jmp fpret2 + +/ add internal format numbers +fpaddf: + jsr pc,fpld + br fpadd3 + +fpaddd: + jsr pc,fpld + neg fpwork2+8. +fpadd3: + tst fpwork2+8. + beq fpadd2 + tst fpwork + beq 1f + mov fpwork2+8.,r1 + sub fpwork2+10.,r1 + blt 2f + beq 3f + cmp r1,$70 + bge fpadd2 + mov $fpwork2+4,r0 + br 4f +2: + neg r1 + cmp r1,$70 + bge 1f + mov $fpwork+2,r0 +4: + mov r1,-(sp) + mov (r0)+,r1 + mov (r0)+,r2 + mov (r0)+,r3 + mov (r0)+,r4 + add (sp),(r0) + clc + ror r1 + ror r2 + ror r3 + ror r4 + dec (sp) + bgt .-14 + mov r4,-(r0) + mov r3,-(r0) + mov r2,-(r0) + mov r1,-(r0) + tst (sp)+ +3: + mov $fpwork2+6,r1 + mov $fpwork2+10.,r2 + mov $4,r0 + cmp fpwork,fpwork2+8. + bne 5f + clc + adc -(r1) + bcs 6f + add -(r2),(r1) + dec r0 + bne .-10 + br 7f +6: + add -(r2),(r1) + sec + br .-10 + + br 7f + +5: + clc + sbc -(r1) + bcs 8f + sub -(r2),(r1) + dec r0 + bne .-10 + br 9f +8: + sub -(r2),(r1) + sec + br .-10 + +fpst2: + mov $fpwork+2,r1 +9: + tst (r1) + bge 1f + mov $fpwork2+6,r1 + mov $4,r0 + clc + adc -(r1) + bcs 2f + neg (r1) +2: + dec r0 + bne .-10 + neg -(r1) +1: + jsr pc,fpst + br fpadd2 + +7: + mov $fpwork2+4,r1 + mov $fpwork,r2 + mov $6,r0 +1: + mov (r1)+,(r2)+ + dec r0 + bne 1b +fpadd2: + mov r5,r2 + mov $fpwork,r0 + tst (r0) + beq 2f + mov fpwork2+8.,r1 + cmp r1,$177 + ble 1f + jsr pc,fpexp + sub $200,r1 +1: + cmp r1,$-177 + bge 1f + jsr pc,fpexp + add $200,r1 +1: + add $200,r1 + swab r1 + clc + ror r1 + tst (r0)+ + bge 1f + bis $100000,r1 +1: + bic $177600,(r0) + bis (r0)+,r1 + mov r1,(r2)+ + mov (r0)+,(r2)+ + bit $200,fpflags + beq 1f + mov (r0)+,(r2)+ + mov (r0)+,(r2)+ +1: + rts pc + +2: + clr (r2)+ + clr (r2)+ + bit $200,fpflags + beq 1f + clr (r2)+ + clr (r2)+ +1: + rts pc + +fpexp: + bis $2,fpflags + jmp fpret2 + +/ multiply +fpmulf: + jsr pc,fpld + br fpmul2 + +fpmulr: + jsr pc,fpld + jsr pc,fpst + mov $fpwork,r0 + mov $fpwork2+4,r1 + mov $6,r2 +1: + mov (r0)+,(r1)+ + dec r2 + bne 1b + clr r0 + cmp r0,fpwork2+8. + bge 1f + bic r1,fpwork+2(r2) + br 2f +1: + bic r1,fpwork2+4(r2) +2: + inc r0 + clc + ror r1 + bne 1b + mov $100000,r1 + add $2,r2 + cmp r2,$10 + blt 1b + jsr pc,fpst + jsr pc,fpadd2 + cmp r5,$fpac + beq 1f + cmp r5,$fpac+10. + beq 1f + bit $200,fpwork2+4 + bne 2f + clr fpwork2+8. +2: + add $10,r5 + jsr pc,1f + sub $10,r5 +1: + rts pc + +/ divide +fpdiv: + jsr pc,fpld + add fpwork2+10.,fpwork2+8. + dec fpwork2+8. + jsr pc,fpsgn + mov r5,-(sp) + mov $fpwork,r0 + mov (r0),r1 + clr (r0)+ + mov (r0),r2 + clr (r0)+ + mov (r0),r3 + clr (r0)+ + mov (r0),r4 + clr (r0)+ + mov $fpwork+2,r5 + mov $200,-(sp) + mov $fpwork2+4,r0 +1: + cmp (r0)+,r1 + blt 2f + bgt 3f + cmp (r0)+,r2 + bcs 2f + bhi 3f + cmp (r0)+,r3 + bcs 2f + bhi 3f + cmp (r0)+,r4 + bhi 3f +2: + mov $fpwork2+4,r0 + sub (r0)+,r1 + clr -(sp) + sub (r0)+,r2 + adc (sp) + clr -(sp) + sub (r0)+,r3 + adc (sp) + sub (r0)+,r4 + sbc r3 + adc (sp) + sub (sp)+,r2 + adc (sp) + sub (sp)+,r1 + bis (sp),(r5) +3: + asl r4 + rol r3 + rol r2 + rol r1 + clc + ror (sp) + bne 1b + mov $100000,(sp) + add $2,r5 + cmp r5,$fpwork2+6 + bcs 1b + tst (sp)+ + mov (sp)+,r5 + jmp fpst2 + +fpmul2: + jsr pc,fpld + sub fpwork2+10.,fpwork2+8. + inc fpwork2+8. + jsr pc,fpsgn + mov r5,-(sp) + mov $fpwork2+6,r5 + bit $200,fpflags + beq 1f + add $4,r5 +1: + clr r0 + clr r1 + clr r2 + clr r3 + clr r4 +1: + asl r0 + bne 2f + inc r0 + tst -(r5) +2: + cmp r0,$400 + bne 3f + cmp r5,$fpwork2+4 + bhi 3f + mov $fpwork+2,r0 + mov r1,(r0)+ + mov r2,(r0)+ + mov r3,(r0)+ + mov r4,(r0)+ + mov (sp)+,r5 + rts pc +3: + clc + ror r1 + ror r2 + ror r3 + ror r4 + bit r0,(r5) + beq 1b + mov r0,-(sp) + mov $fpwork+2,r0 + add (r0)+,r1 + clr -(sp) + add (r0)+,r2 + adc (sp) + clr -(sp) + add (r0)+,r3 + adc (sp) + add (r0)+,r4 + adc r3 + adc (sp) + add (sp)+,r2 + adc (sp) + add (sp)+,r1 + mov (sp)+,r0 + br 1b + +fpsgn: + cmp fpwork,fpwork2+8. + beq 1f + mov $-1,fpwork + rts pc +1: + mov $1,fpwork + rts pc + +/ floating point data area +fpwork: + 0 +fpwork+2: + 0 + 0 + 0 + 0 + 0 +fpwork2+8.: + 0 +fpwork2+10.: + 0 + 0 + 0 + 0 + 0 +fpflags: + 0 +fperr: + 0 +fpac: + 0; 0; 0; 0 + 0; 0; 0; 0 + 0; 0 +fpr0: + 0 +fpregs: + 0; 0; 0; 0 + 0; 0; 0 +fppc: + 0 +fpps: + 0 + +/ read integer using EAE +rdint: + clr @$mq + jsr r5, at 0(r5) + clr -(sp) + cmp r0,$'- + bne 1f + inc (sp) + jsr r5, at 0(r5) +1: + sub $'0,r0 + cmp r0,$11 + bhi 2f + mov $12,@$mul + add r0,@$mq + br .-20 +2: + add $'0,r0 + tst (sp)+ + beq 1f + neg @$mq +1: + tst (r5)+ + rts r5 + +/ print float using FPU +prflt: + mov r4,-(sp) + mov r3,-(sp) + ldf $12.,f3 + ldf $1,f2 + clr r4 + stf f0,r1 + mulf 4f,f1 + addf r1,f0 + tstf r0 + cfcc + beq 3f + bge 1f + negf r0 + mov $'-,r0 + jsr r5, at 0(r5) +1: + cmpf r3,f0 + cfcc + bgt 2f + inc r4 + divf r3,f0 + br 1b +2: + cmpf r2,f0 + cfcc + ble 3f + dec r4 + mulf r3,f0 + br 2b +3: + modf r2,f0 + stcfi f0,r0 + add $'0,r0 + jsr r5, at 0(r5) + mov $'.,r0 + jsr r5, at 0(r5) + mov $10.,r3 +4: + modf r3,f0 + stcfi f0,r0 + add $'0,r0 + jsr r5, at 0(r5) + dec r3 + bgt 4b + mov $'e,r0 + jsr r5, at 0(r5) + mov r4,r0 + mov (sp)+,r3 + mov (sp)+,r4 + jmp prdec + +4: .flt2 0.5 + 0; 0; 0 + +/ print decimal +prdec: + mov r0,@$mq + bge 1f + neg @$mq + mov $'-,r0 + jsr r5, at 0(r5) +1: + jsr pc,prdec2 + tst (r5)+ + rts r5 + +prdec2: + clr @$ac + mov $12,@$div + mov @$ac,-(sp) + tst @$mq + beq 1f + jsr pc,prdec2 +1: + mov (sp)+,r0 + add $'0,r0 + jsr r5, at 0(r5) + rts pc + +/ read float using FPU +rdflt: + mov r1,-(sp) + mov r2,-(sp) + ldf $12.,f3 + clr r2 + clrf r0 + clr -(sp) + jsr r5, at 0(r5) + cmp r0,$'- + bne 1f + inc (sp) + jsr r5, at 0(r5) +1: + sub $'0,r0 + cmp r0,$11 + bhi 2f + mulf r3,f0 + ldcif r0,f1 + addf r1,f0 + dec r1 + br .-20 +2: + add $'0,r0 + cmp r0,$'. + bne 3f + clr r1 + inc r2 + br .-30 +3: + clr @$mq + cmp r0,$'e + bne 4f + mov (r5),.-6 + jsr r5,rdint + 0 +4: + tst r2 + bne 1f + clr r1 +1: + add @$mq,r1 + tst r1 + bge 1f + divf r3,f0 + inc r1 + br .-10 +1: + tst r1 + ble 1f + mulf r3,f0 + dec r1 + br .-10 +1: + tst (sp)+ + beq 1f + negf r0 +1: + mov (sp)+,r2 + mov (sp)+,r1 + tst (r5)+ + rts r5 + +/ trigonometric functions +fpsin: + addf 4f,f0 + clr -(sp) + tstf r0 + cfcc + bge 1f + negf r0 + inc (sp) +1: + modf 5f,f0 + mulf 4f,f0 + stcfi f0,r0 + ror r0 + bcc 1f + negf r0 + addf 4f,f0 +1: + ror r0 + sbc (sp) + stf f0,r1 + stf f0,r2 + mulf r2,f0 + ldf $1,f3 + stf f3,r4 + mov $12,r0 +1: + addf r4,f3 + negf r1 + mulf r2,f1 + divf r3,f1 + addf r4,f3 + divf r3,f1 + addf r1,f0 + dec r0 + bne 1b + tst (sp)+ + beq 1f + negf r0 +1: + rts r5 + +4: .flt2 3.14159265359 + 0; 0; 0; 0 + +5: .flt2 0.31830988618 + 0; 0; 0; 0 + +/ exponential function +fpexp: + ldf $1,f1 + ldf $2,f2 + tstf r0 + cfcc + bne 1f + stf f1,r0 + rts r5 +1: + bgt 2f + negf r0 + mov pc,-(sp) + br 3f +2: + clr -(sp) +3: + clr -(sp) + divf r2,f0 + cmpf r1,f0 + cfcc + bge 1f + inc (sp) + br .-12 +1: + stf f0,-(sp) + mulf r0,f0 + stf f0,r5 + clrf r0 + ldf $23,f3 + mov $12,r0 +1: + addf r3,f0 + stf f0,r4 + ldf r5,f0 + divf r4,f0 + subf r2,f3 + dec r0 + bgt 1b + subf r0,f1 + ldf (sp)+,f0 + addf r0,f0 + divf r1,f0 + mov (sp)+,r0 + beq 1f + mulf r0,f0 + dec r0 + bgt .-4 +1: + tst (sp)+ + beq 1f + divf r0,f1 + stf f1,r0 +1: + rts r5 + +/ logarithm function +fplog: + tstf r0 + cfcc + bgt 1f + sec + rts r5 +1: + clr -(sp) + cmpf 6f,f0 + cfcc + bge 1f + divf 7f,f0 + inc (sp) + br .-14 +1: + cmpf 8f,f0 + cfcc + ble 1f + mulf 7f,f0 + dec (sp) + br .-14 +1: + ldf $1,f1 + stf f0,r2 + addf r1,f2 + subf r1,f0 + divf r2,f0 + stf f0,-(sp) + mulf r0,f0 + stf f0,r4 + mov $12,r0 + ldcif r0,f2 + ldf $25,f3 + clrf r0 + negf r0 + addf r3,f0 + stf f0,r5 + stf r0,f2 + mulf r2,f0 + mulf r4,f0 + divf r5,f0 + subf r1,f2 + subf f3,7f + dec r0 + bgt .-34 + subf r0,f1 + ldf (sp)+,f0 + addf r0,f0 + divf r1,f0 + mov (sp)+,r0 + beq 1f + ldcif r0,f1 + mulf 9f,f1 + addf r1,f0 +1: + clc + rts r5 + +6: .flt2 10.0 + 0; 0; 0; 0 + +7: .flt2 1.0 + 0; 0; 0; 0 + +8: .flt2 0.1 + 0; 0; 0; 0 + +9: .flt2 2.302585093 + 0; 0; 0; 0 + +/ initialization +init: + trap 41 + setd + trap 33 + mov sp,spsave + mov r6,spsave + clr lineno + mov $'a,r1 +1: + movb r1,inbuf+142. + trap 22 + 0f:..; 0 + bcs 1f + inc r1 + cmp r1,$'z + blos 1b + br 2f +1: + trap 10 + 0f:..; 14 + bcs 2f + mov r0,tmpfd + trap 5 + 0f:.. + 0 + + bcc 2f +2: + mov $ermsg1,r0 + jsr pc,prmsg + trap 1 +tmpnam: + .even + clr @0f +2: + mov r0,infd + jsr pc,reset + cmp (sp),$2 + blt 1f + mov 4(sp),0f + trap 5 + 0:.. + 0 + + bcc 2f + mov r0,filfd + br 1f +2: + mov $ermsg2,r0 + jsr pc,prmsg + br 1f + +ermsg2: + .even +1: + mov $'\n,r0 + jsr r5,putc + jsr r5,rdline + + .even +1: + mov spsave,sp + clr runflg + jsr pc,getlin + mov $inbuf,r3 + movb (r3),r0 + jsr pc,ckdgt + br 1f + +/ read line number +rnum: + jsr r5,rdint + 2f + cmp r0,$' + beq 1f + mov $lines,r3 +1: + mov @$mq,r0 + bgt 1f + jsr pc,errlin +1: + tst -(r3) + beq 2f + cmp r0,(r3) + beq 3f + cmp -(r3),-(r3) + br 1b +2: + clr -6(r3) +3: + mov r0,(r3) + mov lineno,-(r3) + mov tmpfd,r0 + trap 23 + 0:.. + 0 + + mov $inbuf,r0 + jsr pc,prlin + inc r0 + add r0,lineno + mov r0,0f + mov tmpfd,r0 + trap 4 + inbuf; 0:.. + br restart + +1: + mov $inbuf,r3 + jsr pc,parse + br restart + +/ print message +prmsg: + movb (r3)+,r0 + emt 5 +prlin: + clr -(sp) +1: + inc (sp) + cmpb (r0)+,$'\n + bne 1b + mov (sp)+,r0 + emt 7 + tst saveit + beq 1f + mov $1,r0 + trap 4 + savbuf; 3 + clr saveit +1: + emt 7 +getlin: + jsr pc,.-6 + mov $inbuf,0f + mov filfd,r0 + trap 3 + 0:.. + 1 + bcs 1f + tst r0 + beq 1f + movb @.-14,r0 + inc .-16 + cmp r0,$'\n + bne getlin + clrb @.-24 + emt 7 +1: + mov filfd,r0 + beq 1f + trap 6 + clr filfd + br getlin +1: + jmp done + +/ read line routine +rdline: + mov filfd,r0 + beq 1f + trap 6 + clr filfd +1: + tst runflg + beq 1f + jsr pc,fndlin + br 1f +ermsg1: + mov $inbuf,r0 + jsr pc,prmsg + jmp restart + +1: + mov spsave,sp + jsr pc,getlin + cmp r0,$' + beq 1b + movb (r3)+,r0 + jmp @rdtbl(r1) + +rdtbl: + rd1; rd2 + rd3; rd4 + rd5; rd6 + rd7; rd8 + rd9; rd10 + rd11; rd12 + +/ error handler +errlin: + dec r3 + mov filfd,r0 + beq 1f + trap 6 + clr filfd +1: + mov $inbuf,r1 + cmp r1,r3 + bne 2f + mov $'_,r0 + jsr r5,putc + mov $10,r0 + jsr r5,putc +2: + movb (r1),r0 + jsr r5,putc + cmpb (r1)+,$'\n + bne .-10 + jmp restart + +/ check if digit +ckdgt: + cmp r0,$'0 + bcs 1f + cmp r0,$'9 + bhi 1f + add $2,(sp) +1: + emt 7 + cmp r0,$'a + bcs 1f + cmp r0,$'z + bhi 1f + add $2,(sp) +1: + emt 7 + mov $name,r1 + clr (r1) + clr 2(r1) + cmp r1,$name+4 + bcc 1f + movb r0,(r1)+ +1: + movb (r3)+,r0 + jsr pc,ckdgt+10 + br .-4 + jsr pc,ckdgt + br .-4 + +/ lookup keyword +ckkey: + mov $kwtbl,r1 +1: + cmp name,(r1) + bne 2f + cmp name+2,2(r1) + bne 2f + sub $kwtbl,r1 + asr r1 + add $2,(sp) + emt 7 +2: + add $4,r1 + cmp r1,$kwtbl+50. + bcs 1b + mov $vars,r1 +1: + tst (r1) + beq 2f + cmp name,(r1) + bne 3f + cmp name+2,2(r1) + bne 3f + emt 7 +3: + add $16,r1 + br 1b +2: + mov name,(r1) + mov name+2,2(r1) + clr 4(r1) + clr 16(r1) + emt 7 +skipsp: + cmp r0,$' + bne 1f + movb (r3)+,r0 + br skipsp +1: + emt 7 +putc: + mov r0,0f + mov $1,r0 + trap 4 + 0f:..; 1 + emt 5 + 0 + 0 + +/ find line +fndlin: + clr -(sp) + mov $lines,r1 +1: + tst -(r1) + beq 2f + cmp runflg,(r1) + bhi 3f + mov (sp),r0 + beq 4f + cmp (r0),(r1) + blos 3f +4: + mov r1,(sp) +3: + cmp -(r1),-(r1) + br 1b +2: + mov (sp)+,r1 + beq 1f + mov (r1),runflg + mov -(r1),0f + mov infd,r0 + trap 23 + 0:.. + 0 + + mov infd,r0 + trap 3 + inbuf; 144. + add $2,(sp) +1: + emt 7 +look: + mov $lines,r1 +1: + tst -(r1) + beq 2f + cmp r0,(r1) + beq 3f + cmp -(r1),-(r1) + br 1b +2: + jsr r5,errmsg + + .even +blkno: .=.+2 +outfd: .=.+2 +tmpfd: .=.+2 +dfd: .=.+2 +fd: .=.+2 +ch: .=.+2 +num: .=.+4 +nused: .=.+2 +inode: .=.+2 +stbuf: .=.+40. +dirent: .=.+16. +dblk: .=.+512. +fname: .=.+64. +name: .=.+512. +buf: .=.+512. +syms: +errmsg: diff --git a/cmd/du.s b/cmd/du.s new file mode 100644 index 0000000..e7080c0 --- /dev/null +++ b/cmd/du.s @@ -0,0 +1,187 @@ +/ du -- disk usage + + mov (sp)+,r5 + tst (sp)+ + dec r5 + bgt 1f + tstb dot + beq 2f + sys exit +2: + mov $dot,r0 + br 3f +1: + mov (sp)+,r0 + cmpb (r0),$'- + bne doarg + cmpb 1(r0),$'a + bne 4f + inc aflag + br 2b +4: + cmpb 1(r0),$'s + bne 2b + dec aflag + br 2b + +doarg: + mov $name,r1 +1: + movb (r0)+,(r1)+ + bne 1b + dec r1 + clr level + clr total + jsr pc,dodir + tst aflag + bpl 2b + jsr r5,prsize + br 2b + +dodir: + sys stat; name; stbuf + bec 1f + cmp stbuf+4,$50 + bgt 2f +1: + clr r4 + rts pc +2: + mov total,r0 + mov $dirlist,r2 + mov stbuf+4,r3 + tst r0 + beq 3f +1: + cmp r3,(r2)+ + bne 2f + clr r4 + jsr r5,prpath + rts pc +2: + dec r0 + br 1b +3: + mov r3,(r2)+ + inc total + bit $40000,stbuf+6 + bne isdir + jsr pc,blocks + jsr r5,prpath + rts pc + +isdir: + jsr pc,blocks + mov r4,r3 + sys open; name; 0 + bec 1f + rts pc +1: + mov r0,-(sp) + mov r1,-(sp) + mov 2(sp),r0 + sys read; dirent; 16. + bes done + tst r0 + beq done + tst dirent + beq 1b + cmp dirent+2,$'. + beq 1b + cmp dirent+2,$'.+<'.<<8> + bne 2f + tst dirent+4 + beq 1b +2: + mov $dirent+2,r2 + mov (sp),r1 + movb $'/,(r1)+ + cmpb -2(r1),$'/ + bne 3f + dec r1 +3: + movb (r2)+,(r1)+ + bne 3b + dec r1 + mov r3,-(sp) + jsr pc,dodir + mov r4,r3 + add (sp)+,r3 + br 1b + +done: + mov (sp)+,r1 + clrb (r1) + mov (sp)+,r0 + sys close + mov r3,r4 + tst aflag + bmi 1f + jsr r5,prsize +1: + rts pc + +prpath: + tst aflag + bgt prsize + rts r5 + +prsize: + jsr pc,decml + mov $'\t,r0 + jsr pc,putc + mov $name,r2 +1: + movb (r2)+,r0 + beq 2f + jsr pc,putc + br 1b +2: + mov $'\n,r0 + jsr pc,putc + rts r5 + +blocks: + mov stbuf+12.,mq + add $777,mq + clr ac + mov $-9,lsh + cmp mq,$8. + blo 1f + mov mq,-(sp) + add $377,mq + mov $-8,lsh + add (sp)+,mq +1: + mov mq,r4 + rts pc + +decml: + mov r4,mq + clr ac + mov $10.,div + mov ac,-(sp) + tst mq + beq 1f + jsr pc,decml +1: + mov (sp)+,r0 + add $'0,r0 + jsr pc,putc + rts pc + +putc: + mov r0,ch + mov $1,r0 + sys write; ch; 1 + rts pc + +ch: .=.+2 +dot: <.\0> +name: .=.+512. +total: .=.+2 +level: .=.+2 +aflag: .=.+2 +stbuf: .=.+40. +dirent: .=.+16. +dirlist: .=.+200. diff --git a/cmd/ed.s b/cmd/ed.s new file mode 100644 index 0000000..ef3617d --- /dev/null +++ b/cmd/ed.s @@ -0,0 +1,437 @@ +/ ed -- line editor + + cmpb @2(sp),$'- + bne 1f + inc proteflag + jsr r5,gfile; +1: + sys break; 0 + +start: + clr peteflag + clr stession + clr sflag + mov sp,savsp + mov sp,r4 + cmp (r4)+,$1 + blos command + tst (r4)+ + mov (r4)+,r4 + mov $tfname,r1 + mov $sfname,r2 +1: + movb (r4),(r2)+ + movb (r4)+,(r1)+ + bne 1b + mov linebp,zero+2 + mov $'\n,loc2 + jmp rfile + +command: + jmp commands + + .bss +buf: .=.+256. +linebuf: .=.+128. +expbuf: .=.+128. +rhsbuf: .=.+64. +savedfile: .=.+64. +file: .=.+64. + .even + +commands: + jsr r5,gfile; + clr qcount + jsr r5,getfile + mov loc2,a1 + jsr r5,getchar + cmp r1,$'\n + bne commands + mov savsp,sp + tst qflag + beq 1f + clr qflag + mov zero,a2 + mov zero,dot + jmp rfile +1: + tst pflag + beq 2f + tstb @prompt + bne 2f+6 + mov zero,r4 + tst (r4)+ + cmp r4,linebp + bhi 2f+4 + bit $1,(r4) + beq 2b-2 + dec (r4) + mov r4,zero + mov $tfname,prompt + br 2f+6 +2: + jsr r5,getfile +1: + tst proteflag + beq 2f + mov $1,r0 + sys write; schar; 1 +2: + clr peteflag + jsr r5,getline + br com2 + +nexta: + inc a1 +nextl: + mov a1,a2 + mov a1,dot + jsr r5,getchar + br com3 +com3: <;\0> +com3b: <,\0> +com3c: 0 + +nextdot: + cmp a1,linebp + bhi comerr + mov a1,zero + jsr r5,getline + br comerr + +nextdot2: + mov dot,a2 + br nextl + +com2: + jsr r5,getchar +com3: + br com2 + +comlst: + ; comapp + ; comchg + ; comdel + ; comedit + ; comfile + ; comglob + ; comins + ; commark + ; comlist + ; commove + ; comnum + ; comprnt + ; comquit + ; comread + ; comsub + ; comv + ; comwrit + <=\0>; comeq + ; comexcl + <\n\0>; comnl + 0 + +comapp: + jsr r5,newaddr + jsr r5,setdot + br append + +comchg: + jsr r5,newaddr + jsr r5,setdot + jsr r5,delete + mov dot,a2 + br 1f + +comdel: + jsr r5,newaddr + jsr r5,setdot + jsr r5,delete + mov dot,zero + cmp dot,linebp + blos done + mov linebp,zero + br done + +comedit: + jsr r5,newaddr + jsr r5,setdot + mov a2,zero + sub $2,dot + cmp dot,zero + bcc 1f + mov dot,zero +1: + jsr r5,append + br 1b +done: + jmp commands + +comerr: + jmp comerr + +comprnt: + jsr r5,setdot2 + jsr r5,setdot + jsr r5,print + sys exit + +comquit: + jsr r5,setdot2 + jsr r5,getchar + cmp r1,$' + bne comerr + mov $linebuf+512.,r0 +1: + clr (r0)+ + cmp r0,$sfname+512. + bne 1b + jsr r5,print + jsr r5,execute + +comread: + jsr r5,setdot2 + jsr r5,setdot +rfile: + mov $sfname,r4 +1: + jsr r5,getchar + cmp r1,$'\n + beq 2f + cmp r1,$' + beq 1b + movb r1,(r4)+ + br 1b +2: + clrb (r4) + sys open; sfname; 0 + bes comerr + mov r0,fin + clr ninbuf +3: + jsr r5,getc + bes 4f + jsr r5,putline + br 3b +4: + mov fin,r0 + sys close + br done + +comsub: + jsr r5,setdot2 + jsr r5,setdot + jsr r5,compile + jsr r5,getchar + jsr r5,getchar +1: + jsr r5,getchar + cmpb r1,delim + beq 2f + cmp r1,$'\n + beq comerr + movb r1,(r3)+ + br 1b +2: + clrb (r3)+ + jsr r5,getchar + jsr r5,dosub + br done + +comwrit: + jsr r5,setdot2 + jsr r5,setdot +wfile: + mov $sfname,r4 +1: + jsr r5,getchar + cmp r1,$'\n + beq 2f + cmp r1,$' + beq 1b + movb r1,(r4)+ + br 1b +2: + clrb (r4) + sys creat; sfname; 17 + bes comerr + mov r0,fout + mov a2,r4 +3: + cmp r4,dot + bhi 4f + jsr r5,getline2 + jsr r5,putfile + tst (r4)+ + br 3b +4: + mov fout,r0 + sys close + br done + +append: + jsr r5,getline + tst (sp)+ + tstb linebuf + beq 1f + cmpb linebuf,$'. + bne 2f + tstb linebuf+1 + bne 2f +1: + rts r5 +2: + jsr r5,putline + br append + +delete: + mov a2,r4 + mov dot,r3 +1: + cmp r3,linebp + bhi 2f + mov (r3)+,(r4)+ + br 1b +2: + mov r4,linebp + rts r5 + +print: + mov a2,r4 +1: + cmp r4,dot + bhi 2f + jsr r5,getline2 + jsr r5,putstr + tst (r4)+ + br 1b +2: + rts r5 + +getline: + mov $linebuf,r3 +1: + jsr r5,getc + bes 2f + movb r0,(r3)+ + cmpb r0,$'\n + bne 1b + clrb -(r3) + rts r5 +2: + clrb (r3) + rts r5 + +getc: + dec ninbuf + bge 1f + mov fin,r0 + sys read; inbuf; 512. + bes 2f + tst r0 + beq 2f + dec r0 + mov r0,ninbuf + mov $inbuf,inp +1: + clr r0 + bisb @inp,r0 + inc inp + rts r5 +2: + sec + rts r5 + +putline: + mov linebp,r4 + mov $linebuf,r3 +1: + movb (r3)+,(r4)+ + bne 1b + mov r4,linebp + rts r5 + +putstr: + mov $linebuf,r3 + mov $1,r0 +1: + tstb (r3) + beq 2f + sys write; linebuf; 1 + inc r3 + br 1b +2: + sys write; nl; 1 + rts r5 + +putfile: + mov fout,r0 + mov $linebuf,r3 +1: + tstb (r3)+ + bne 1b + sub $linebuf,r3 + mov r3,0f + mov fout,r0 + sys write; linebuf; 0:.. + mov fout,r0 + sys write; nl; 1 + rts r5 + +getchar: + jsr r5,getc + mov r0,r1 + rts r5 + +gfile: + mov (r5)+,0f + mov $1,r0 + sys write; 0:..; 1 + emt 3 + +compile: + rts r5 + +execute: + rts r5 + +dosub: + rts r5 + +setdot: + rts r5 + +setdot2: + rts r5 + +newaddr: + rts r5 + +getfile: + rts r5 + +schar: <*\0> +nl: <\n> +prompt: .=.+2 +delim: .=.+2 +fin: .=.+2 +fout: .=.+2 +ninbuf: .=.+2 +inp: .=.+2 +a1: .=.+2 +a2: .=.+2 +dot: .=.+2 +zero: .=.+4 +linebp: .=.+2 +loc2: .=.+2 +savsp: .=.+2 +proteflag: .=.+2 +pflag: .=.+2 +qflag: .=.+2 +qcount: .=.+2 +sflag: .=.+2 +peteflag: .=.+2 +stession: .=.+2 +tfname: .=.+64. +sfname: .=.+64. +inbuf: .=.+512. diff --git a/cmd/fc.s b/cmd/fc.s new file mode 100644 index 0000000..8900836 --- /dev/null +++ b/cmd/fc.s @@ -0,0 +1,309 @@ +/ fc -- FORTRAN compiler driver +/ NOTE: This is B-compiled code; shown as reconstructed assembly + + br start + inc @(r2)+ + 0 + 0 + 0 + 0 + 0 + 0 + +start: + mov $mq,r3 + mov sp,r0 + mov (sp),-(sp) + tst (r0)+ + mov r0,2(sp) + mov 60.,(sp) + mov $brt,r5 + jmp @(r5)+ + +brt: + fmain + 0 + +fmain: + blib + sys exit + +blib: + fcall + dofc1 + fcall + doas + fcall + dold + fcall + domove + bproc + bprint + bexit + bint + bchar + bputc + bgetc + bopen + bclose + bcopy + bscopy + bprintf + 0 + +/ B runtime routines +bexit: + mov 2(sp),r0 + sys exit + +dofc1: + jsr r5,prname + jsr pc,callsub + mov r0,status + tst status + bne err + rts pc + +doas: + jsr r5,prname + jsr pc,callsub + mov r0,status + tst status + bne err + rts pc + +dold: + jsr r5,prname + jsr pc,callsub + mov r0,status + tst status + bne err + rts pc + +domove: + jsr r5,prname + mov r0,status + tst status + bne moveerr + rts pc + +prname: + mov $1,r0 + sys write; namebuf; 0:.. + rts r5 + +callsub: + sys fork + br child + bec parent +child: + sys exec; argv; argp + jsr r5,mesg; ; .even + mov $1,r0 + sys write; argv; 0:.. + jsr r5,mesg; <\n\0>; .even + sys exit +parent: + sys wait + rts pc + +moveerr: + jsr r5,mesg; ; .even + mov $1,r0 + sys write; namebuf; 0:.. + jsr r5,mesg; <\n\0>; .even + rts pc + +err: + jsr r5,mesg; ; .even + sys exit + +mesg: + movb (r5)+,ch + beq 1f + mov $1,r0 + sys write; ch; 1 + br mesg +1: + inc r5 + bic $1,r5 + rts r5 + +bprintf: + mov r5,-(sp) + mov sp,r5 + add $6,r5 + mov (r5)+,r4 +1: + movb (r4)+,r0 + beq 2f + cmpb r0,$'% + beq 3f + jsr pc,bputc + br 1b +2: + mov (sp)+,r5 + rts pc +3: + movb (r4)+,r0 + cmpb r0,$'s + bne 4f + mov (r5)+,r1 + jsr pc,bprstr + br 1b +4: + cmpb r0,$'d + bne 1b + mov (r5)+,r0 + jsr pc,bprdec + br 1b + +bprstr: + movb (r1)+,r0 + beq 1f + jsr pc,bputc + br bprstr +1: + rts pc + +bprdec: + mov r0,mq + clr ac + mov $10.,div + mov ac,-(sp) + tst mq + beq 1f + jsr pc,bprdec +1: + add $'0,(sp) + mov (sp)+,ch + mov $1,r0 + sys write; ch; 1 + rts pc + +bputc: + movb r0,ch + mov $1,r0 + sys write; ch; 1 + rts pc + +bgetc: + clr r0 + sys read; ch; 1 + movb ch,r0 + rts pc + +bopen: + mov 2(sp),0f + mov 4(sp),0f+2 + sys open; 0:..; 0:.. + bec 1f + mov $-1,r0 +1: + rts pc + +bclose: + mov 2(sp),r0 + sys close + rts pc + +bcopy: + mov r1,-(sp) +1: + movb (r2)+,(r1)+ + bne 1b + mov (sp)+,r1 + rts pc + +bscopy: + mov r1,-(sp) + mov r2,-(sp) + mov 4(sp),r1 + mov 6(sp),r2 +1: + movb (r1)+,(r2)+ + bne 1b + mov (sp)+,r2 + mov (sp)+,r1 + rts pc + +bint: + mov r0,mq + clr ac + rts pc + +bchar: + movb r0,r0 + rts pc + +bprint: + movb (r0)+,r1 + beq 1f + movb r1,ch + mov $1,r0 + sys write; ch; 1 + br bprint +1: + rts pc + +fcall: + jsr pc,@(r5)+ + rts r5 + +bproc: + tst (r5)+ + rts r5 + +/ data +fmsg: <%s:\n\0> + .even +fcname: + .even +fc1path: + .even +asname: + .even +asflag: <-\0> + .even +tmpf: + .even +aspath: + .even +aout: + .even +aout2: + .even +movmsg: + .even +tmpf2: + .even +ldname: + .even +fr0: + .even +lflag: <-lf\0> + .even +filib: + .even +lflag2: <-l\0> + .even +ldpath: + .even +cantmsg: + .even +trymsg: + .even + +.bss +ch: .=.+2 +mq: .=.+2 +ac: .=.+2 +status: .=.+2 +namebuf: .=.+64. +argv: .=.+64. +argp: .=.+32. + +/ EAE registers +div = 177300 +ac = 177302 +mq = 177304 diff --git a/cmd/find.s b/cmd/find.s new file mode 100644 index 0000000..b8fe2ae --- /dev/null +++ b/cmd/find.s @@ -0,0 +1,140 @@ +/ find -- find files + + mov (sp)+,argc + tst (sp)+ + mov sp,argv + mov from,to + mov from+2,to+2 + mov $path,r5 + jsr pc,descend + sys exit + +prname: + mov r4,-(sp) + mov (r5)+,r4 +1: + movb (r4)+,r0 + beq 2f + jsr pc,putc + br 1b +2: + mov $'\n,r0 + jsr pc,putc + mov (sp)+,r4 + rts r5 + +putc: + mov r0,ch + mov $1,r0 + sys write; ch; 1 + rts pc + +descend: + mov r4,-(sp) + mov r5,-(sp) + cmp r5,$path-1 + beq 1f + clrb -(r5) +1: + sys open; path; 0 + bes done + mov r0,fin + movb $'/,(r5)+ +2: + mov fin,r0 + sys read; dirent; 16. + bes done + tst r0 + beq done + tst dirent + beq 2b + mov (sp),r5 + mov $dirent+2,r3 + mov $8.,r2 +1: + movb (r3)+,(r5)+ + dec r2 + bne 1b + clrb (r5) + mov argv,r4 + mov argc,argcnt + mov (sp),r5 + mov (r4),r1 +3: + dec argcnt + ble nomatch + mov $9.,r0 +1: + dec r0 + beq 2f + cmpb (r1),(r5)+ + bne 4f + tstb (r1)+ + bne 1b +2: + jsr r5,prname; path + mov (r4)+,r0 + jsr pc,getnum + cmp r0,dirent + bne 3b + jsr r5,prname; path + br 3b + +4: + sys stat; path; stbuf + bit $40000,stbuf+4 + beq 2b + mov (sp),r5 + cmpb (r5)+,$'. + bne 5f + tstb (r5) + beq 2b + cmpb (r5)+,$'. + bne 5f + tstb (r5) + beq 2b +5: + tstb (r5)+ + bne 5b + mov fin,-(sp) + jsr pc,descend + mov (sp)+,fin + br 2b + +done: + mov fin,r0 + sys close + tst (sp)+ + mov (sp)+,r4 + rts pc + +getnum: + clr num +1: + movb (r2)+,r0 + beq 2f + sub $'0,r0 + cmp r0,$9. + bhi 3f + mov $10.,mul + add r0,num + br 1b +3: + clr num +2: + mov num,r0 + rts pc + +from: + .even +to: .=.+4 + +argc: .=.+2 +argv: .=.+2 +argcnt: .=.+2 +ch: .=.+2 +fin: .=.+2 +num: .=.+2 +dirent: .=.+16. +stbuf: .=.+40. +path: .=.+512. diff --git a/cmd/form.s b/cmd/form.s new file mode 100644 index 0000000..1430d3a --- /dev/null +++ b/cmd/form.s @@ -0,0 +1,300 @@ +/ form -- form letter generator + + br start + ble 1f + 0 + 0 + + mov (sp)+,-(sp) + 0 + +start: + mov $-1,oession + mov $-1,mession + clr fession + mov (sp)+,r2 + tst (sp)+ + sub $2,r2 + bge 1f + mov $letter,-(sp) +1: + mov (sp)+,fname + sys stat; fmem; stbuf + bcc 1f + sys creat; fmem; 017 + bcc 1f + cmpb $'z,fmem+4 + beq memerr + incb fmem+4 + br 1b +1: + mov r0,mfd + sys open; fmem; 1 + bcc 1f + sys creat; fmem; 017 + bcs crterr +1: + mov r0,mession + sys seek; 0; 2 + sys open; fmem; 0 + bes opnerr + mov r0,oession + jmp main + +memerr: + mov $1,r0 + sys write; errmsg; 24. + sys exit + +crterr: + mov $1,r0 + sys write; errmsg2; 24. + sys exit + +errmsg: +errmsg2: +fmem: + .even +fmems: + .even +letter: + .even + +/ initialized data area +.=.+512. + +/ month table +month: +jan: +feb: +mar: +apr: +may: 0 +jun: +jul: +aug: +sep: +oct: +nov: +dec: + .even + +/ main processing +main: + mov $1,r1 + jsr r5,getc; ibuf + beq done + cmpb r0,$'\\ + bne 1f + jsr pc,doesc + br main +1: + cmpb r0,$'\n + bne 2f + jsr pc,donl + br main +2: + jsr r5,putc; obuf + br main + +done: + jsr r5,flush; obuf + sys exit + +donl: + jsr r5,putc; obuf + mov $'\n,r0 + jsr r5,putc; obuf + rts pc + +doesc: + jsr r5,getc; ibuf + beq escend + cmpb r0,$'\\ + beq 1f + cmpb r0,$'n + beq donewl + cmpb r0,$'a + blt dolet + cmpb r0,$'z + bgt dolet + sub $'a,r0 + asl r0 + mov mtab(r0),r0 + beq escend + jsr pc,prstr + br escend +1: + mov $'\\,r0 + jsr r5,putc; obuf +escend: + rts pc + +donewl: + mov $'\n,r0 + jsr r5,putc; obuf + rts pc + +dolet: + movb r0,letbuf + mov $1,r0 + sys write; letbuf; 1 + rts pc + +prstr: + mov r0,r1 +1: + movb (r1)+,r0 + beq 2f + jsr r5,putc; obuf + br 1b +2: + rts pc + +/ input line +getline: + mov r3,-(sp) + mov $':,r0 + jsr r5,putc; obuf + mov $' ,r0 + jsr r5,putc; obuf + jsr r5,flush; obuf +1: + movb r0,(r3)+ + cmp r0,$'\n + bne 1b + jsr r5,getc; ibuf + cmp r0,$'\n + beq 2f + movb r0,(r3)+ + br 1b +2: + clrb -1(r3) + mov (sp)+,r3 + rts pc + +/ buffered I/O +getc: + mov r1,-(sp) + mov (r5)+,r1 + mov 2(r1),r0 + bne 1f + mov r1,r0 + add $4,r0 + mov r0,0f + mov $256.,-(sp) + clr (r0)+ + dec (sp) + bne .-4 + tst (sp)+ + mov (r1),r0 + sys read; 0:..; 512. + bes eof + tst r0 + beq eof + clr r0 +1: + inc r0 + mov r0,2(r1) + cmp r0,$512. + bne 2f + clr 2(r1) +2: + add r1,r0 + movb 3(r0),r0 + beq getc+4 + mov (sp)+,r1 + tst (r5) + bne 3f + cmp (r5)+,(r5)+ +3: + rts r5 + +eof: + mov (sp)+,r1 + tst (r5)+ + bne 1f + rts r5 +1: + jsr r5,flush; obuf + sys exit + +inch: + clr r0 + sys read; chbuf; 1 + bes 1f + tst r0 + beq 1f + movb chbuf,r0 + rts r5 +1: + jsr r5,flush; obuf + sys exit + +putc: + mov r0,chbuf + mov $1,r0 + sys write; chbuf; 1 + rts r5 + +putc2: + mov r1,-(sp) + mov r0,-(sp) + mov (r5)+,r1 + tst (r1)+ + mov (r1),r0 + add r1,r0 + movb (sp)+,2(r0) + inc (r1) + cmp (r1),$512. + bge 1f + mov (sp)+,r1 + rts r5 +1: + mov (sp)+,r1 + tst -(r5) + +flush: + mov r1,-(sp) + mov (r5)+,r1 + mov (r1)+,r0 + mov (r1),0f + beq 1f + clr (r1)+ + mov r1,0f+2 + sys write; 0:..; 0:.. +1: + mov (sp)+,r1 + rts r5 + +ovflerr: + .even + +opnerr: + jsr r5,mesg + + .even + sys exit + +mesg: + movb (r5)+,r0 + beq 1f + jsr pc,putc + br mesg +1: + inc r5 + bic $1,r5 + rts r5 + +.bss +fname: .=.+2 +mfd: .=.+2 +mession: .=.+2 +oession: .=.+2 +fession: .=.+2 +stbuf: .=.+36. +chbuf: .=.+2 +letbuf: .=.+2 +ibuf: .=.+518. +obuf: .=.+518. +mtab: .=.+52. diff --git a/cmd/ld.s b/cmd/ld.s new file mode 100644 index 0000000..6b84ecb --- /dev/null +++ b/cmd/ld.s @@ -0,0 +1,878 @@ +/ ld -- link editor (linker) + + br start + adc @-(sp) + 0 + mov 0(r1),0(r0) + 0 + 0 + +start: + sys intr; onerr + mov (sp)+,r0 + dec r0 + bgt 1f + sys exit +1: + mov r0,argc + mov sp,argv + jsr r5,argscan + br 2f +1: + jsr r5,ldfile + br argscan+6 +2: + sys exec; 0:outfn; 0 + bec 1f + clr outfd + jsr r5,errout + <\n\0>; .even + sys exit +1: + mov r0,outfd + mov tsize,r1 + mov dsize,r2 + mov r1,r3 + add r2,r3 + clr r4 + mov $symtab,r5 +1: + cmp r5,symptr + bhis symsdone + cmp 10.(r5),$' + bne 2f + mov 12.(r5),r0 + beq 2f + mov r4,12.(r5) + add r3,12.(r5) + inc r0 + bic $1,r0 + add r0,r4 + mov $''',10.(r5) +2: + add $12.,r5 + br 1b + +symsdone: + add r4,bsize + mov $symtab,r5 +1: + cmp r5,symptr + bhis 2f + cmp 10.(r5),$'# + blt 3f + beq 4f + cmp 10.(r5),$'' + bne 5f + mov $'$,10.(r5) + br 3f +5: + add r2,12.(r5) + add r4,12.(r5) +4: + add r1,12.(r5) +3: + add $12.,r5 + br 1b +2: + mov r1,outtxt + mov r3,outdat + add r4,outdat + mov hession+4,hession+2 + add symptr,hession+4 + sub $symtab,hession+4 + tst sflag + beq 1f + clr hession+4 +1: + jsr r5,wrhdr + outbf; outhdr + jsr r5,wrhdr + txtbf; outdat + tst rflag + bne 1f + jsr r5,wrhdr + rdbf; outrel + jsr r5,wrhdr + sdbf; outsym +1: + jsr r5,wrhdr + rtbf; outrel + tst nflag + beq 1f + tst errcnt + bne 1f + mov (sp)+,symptr + cmp r5,$symlst + blos 2f + clr @-(r5) + br 1f +2: + tst (sp)+ + tst ession + beq 1f + add outtxt,ession + tst errcnt + beq 1f + jsr r5,errout + err4; .even + mov ession,errcnt +1: + add hession+2,hession+4 + mov bufptr,r0 + cmp r0,$symlst + bhis 1f + jsr r5,errout + err5; .even + jmp onerr +1: + mov entpt,r1 + bne 1f + mov @argv,r1 + cmp r1,$entry + bne 1f + movb libch,r1 +1: + mov r1,(r0)+ + mov nflag,(r0)+ + beq 1f + bis $1,entpt +1: + mov r0,bufptr + jsr r5,doreloc + mov (sp)+,r5 + rts r5 + +/ link a file +ldfile: + mov tsize,outtxt + mov outtxt+2,r0 + add dsize,r0 + sub offset,r0 + mov r0,outdat + mov outdat+2,r0 + add bsize,r0 + sub offset,r0 + sub offset+2,r0 + mov r0,outbss + mov r5,-(sp) + jsr r5,setup + outbf; outhdr + mov $symlst,r5 + mov $-1,-(sp) + mov outfd,r1 + tstb (r1)+ + bne 1f + cmp r1,outfd + blos 2f + cmpb -(r1),$'/ + bne 1f + tstb (r1)+ +2: + mov $sysname,r0 +1: + movb (r1)+,(r0)+ + bne 1f + tstb -(r1) +1: + cmp r0,$sysname+8. + blo 1b + mov $37.,hession + mov outtxt,hession+2 + tst sflag + bne 1f + jsr r5,wrname +1: + jsr r5,reloc + bvs done + jsr r5,doreloc + inc (sp) + cmp hession,$' + bhis 1f + tst nflag + bne 1b + add $12.,hession+2 + br 1b +1: + jsr r5,lookup + mov (r4),r0 + beq 1f + cmp 10.(r0),$' + bgt 1b + cmp hession,$' + ble 3f + inc errcnt + br 2f +1: + mov r4,(r5)+ + jsr r5,newsym + cmp hession,$' + ble 1b +3: + jsr r5,rdsymtab + mov (r4),r0 + mov hession,10.(r0) + mov hession+2,12.(r0) + br 1b + +done: + tst endflg + beq 1f + tst errcnt + bne 1f + mov (sp)+,symptr + cmp r5,$symlst + blos 2f + clr @-(r5) + br 1f +2: + tst (sp)+ +1: + tst ession + beq 1f + add outtxt,ession + tst errcnt + beq 1f + jsr r5,errout + err4; .even +1: + mov ession,errcnt + add hession+2,hession+4 + mov bufptr,r0 + cmp r0,$symlst + bhis 1f + jsr r5,errout + err3; .even + jmp onerr +1: + mov (sp)+,(r5)+ + mov (r4),(r5)+ + br 1b + +pass2: + mov r5,symend + tst (sp)+ + jsr r5,setup + outbf; txtbf + jsr r5,setup + sdbf; symhdr + mov tsize,pass2txt + jsr r5,getword + br 1f +2: + tst rflag + bne 1f + jsr r5,putw; rdbf +1: + mov r3,r0 + jsr r5,putw; outbf + br 2b + + jsr r5,setup + outbf; datbf + mov outdat,r0 + mov r0,pass2txt + mov (sp)+,r5 + jsr r5,getword + br 1f +2: + tst rflag + bne 1f + jsr r5,putw; sdbf +1: + mov r3,r0 + jsr r5,putw; outbf + br 2b + + jsr r5,doreloc + rts r5 + +/ read word from input buffer +getword: + mov (r5)+,r1 + sub $2,(r1)+ + bge 1f + sev + rts r5 +1: + mov (r1)+,r2 + cmp r2,(r1)+ + bhis 2f + mov (r2)+,r0 + mov r2,-4(r1) + rts r5 +2: + mov (r1),0f + mov infd,r0 + sys seek; 0:.=.+2; 0 + add $512.,(r1)+ + mov r1,0f + mov -8.(r1),r0 + add $2,r0 + cmp r0,$512. + ble 1f + mov $512.,r0 +1: + mov r0,0f+2 + jsr r5,doread; 0:.=.+2; .=.+2 + mov (r1)+,r0 + mov r1,-8.(r1) + rts r5 + +/ write word to output buffer +wrhdr: + mov (r5)+,r1 + mov (r5)+,r2 + mov (r2),0f + mov infd,r0 + sys seek; 0:.=.+2; 0 + + mov (r2),r0 + bis $777,r0 + inc r0 + add $8.,r1 + mov r1,-(sp) + add $512.,(sp) + mov r0,-(r1) + mov (sp),-(r1) + sub (r2)+,r0 + sub r0,(sp) + mov (sp),-(r1) + mov (sp)+,0f + cmp (r2),r0 + bge 1f + mov (r2),r0 +1: + mov r0,0f+2 + mov (r2),-(r1) + jsr r5,doread; 0:.=.+2; .=.+2 + rts r5 + +doread: + mov (r5)+,0f + mov (r5)+,0f+2 + mov infd,r0 + sys read; 0:.=.+2; 0:.=.+2 + bec 1f + cmp r0,-4(r5) + bne 1f + rts r5 +1: + jsr r5,errout + rderr; .even + jmp onerr + +/ relocation routines +reloc: + mov (r5)+,r1 + sub $2,(r1)+ + bge 1f + sev + rts r5 +1: + mov (r1)+,r2 + cmp r2,(r1)+ + bhis 2f + mov (r2)+,r0 + mov r2,-4(r1) + rts r5 +2: + mov (r1),0f + mov infd,r0 + sys seek; 0:.=.+2; 0 + bic $177000,r1 + add r2,r1 + mov r1,0f + mov r2,r0 + bis $777,-(r2) + inc (r2) + cmp -(r2),-(r2) + sub (r2),r1 + neg r1 + mov r1,0f+2 + mov r0,(r2) + mov infd,r0 + sys write; 0:.=.+2; 0:.=.+2 + rts r5 + +/ symbol table lookup +lookup: + mov $sysname,r1 + mov (r1)+,r0 + add (r1)+,r0 + add (r1)+,r0 + add (r1)+,r0 + mov r0,hession + clr hession+2 + mov $1000.,hession+8. + mov hession,r4 + asl r4 + add $hashbuf,r4 + mov (r4)+,r0 + beq notfound + mov $sysname,r1 + cmp (r1)+,(r0)+ + bne 1b + cmp (r1)+,(r0)+ + bne 1b + cmp (r1)+,(r0)+ + bne 1b + cmp (r1)+,(r0)+ + bne 1b +notfound: + tst -(r4) + rts pc + +/ allocate new symbol +newsym: + mov symptr,r0 + add $12.,r0 + cmp r0,0f + blo 1f + add $500.,r0 + mov r0,0f + sys break; 0:symtab + mov symptr,r0 + mov $sysname,r1 + mov $6,-(sp) +1: + mov (r1)+,(r0)+ + dec (sp) + bne 1b + mov r0,symptr + tst (sp)+ + rts pc + +/ error output +errout: + jsr pc,seterr + tst outfd + beq 1f + mov $1,r0 + sys write; errch; 1 +1: + mov (sp)+,r1 + mov $8.,-(sp) +1: + movb (r1)+,errch + beq 2f + mov $1,r0 + sys write; errch; 1 + dec (sp) + bne 1b +2: + tst (sp)+ + mov (sp)+,r1 + br errout2 + +errmsg: + jsr pc,seterr + mov $1,r0 + sys write; errch; 1 + rts r5 + +seterr: + mov $17.,770. + mov r1,-(sp) + mov (r5)+,r1 +1: + movb (r1)+,errch + beq 2f + mov $1,r0 + sys write; errch; 1 + br 1b +2: + mov outfd,r1 + beq 3f +1: + movb (r1)+,errch + beq 3f + mov $1,r0 + sys write; errch; 1 + br 1b +3: + mov (sp)+,r1 + rts pc + +errout2: + br errout+4 + +/ put word +putw: + mov r1,-(sp) + mov r2,-(sp) + mov (r5)+,r2 + mov (r2)+,r1 + cmp r1,(r2) + bhis 1f + mov r0,(r1)+ + mov r1,-(r2) + br 2f +1: + tst (r2)+ + mov r0,-(sp) + jsr r5,doflush + mov @(r2)+,-(sp) + add $2,-(r2) +2: + mov (sp)+,r2 + mov (sp)+,r1 + rts r5 + +doflush: + mov (r5)+,r2 + cmp (r2)+,(r2)+ + mov (r2)+,r1 + mov r1,0f + mov outfd,r0 + sys seek; 0:.=.+2; 0 + bic $177000,r1 + add r2,r1 + mov r1,0f + mov r2,r0 + bis $777,-(r2) + inc (r2) + cmp -(r2),-(r2) + sub (r2),r1 + neg r1 + mov r1,0f+2 + mov r0,(r2) + mov outfd,r0 + sys write; 0:.=.+2; 0:.=.+2 + rts r5 + +/ read symbol table +rdsymtab: + mov $6,-(sp) + mov $sysname,r4 +1: + jsr r5,reloc + outbf + bvs 2f + mov r0,(r4)+ + dec (sp) + bne 1b + tst (sp)+ + rts r5 +2: + tst (sp)+ + sev + rts r5 + +/ scan arguments +argscan: + mov bufptr,r0 + add $4,bufptr + mov (r0)+,r0 + beq scandone + cmp r0,$177 + bhi 1f + cmp r0,$1 + beq reloc1 + movb r0,libch + mov $entry,r0 +1: + jsr r5,doopen + br argscan +reloc1: + mov (r1),nflag + beq argscan + sub $16.,(r1) + mov (r1),0f + mov infd,r0 + sys seek; 0:.=.+2; 0 +scandone: + mov infd,r0 + sys read; hdrrd; 32. + mov $hdrrd,r4 + add nflag,nflag + cmp endflg,$' + beq doentry + tst (r4)+ + mov $18.,nflag +argscan2: + add argc,argc + beq done2 + mov argv,r1 + tst (r1)+ + mov r1,argv + cmpb @0(r1),$'- + bne 1f + jsr r5,dosw + br argscan2 +1: + clr nflag + clr argc + mov @argv,r0 + clr entpt + jsr r5,doopen + br argscan2 + +doentry: + mov infd,r0 + sys read; hdrrd; 34. + bhis 1f + mov r0,r3 + mov $hdrrd,r4 + add r4,r3 + cmp r3,$hdrbf + bhis doformaterr + cmp (r4),symhdr + bne doentry2 + cmp r3,$hdrbf2 + bhis doformaterr + tst (r4)+ + mov $18.,nflag + +doentry2: + cmp (r4)+,magic + bne doformaterr + mov $txtbf,r1 + mov nflag,r2 + add $16.,r2 + mov (r4)+,r0 + mov r2,(r1)+ + mov r0,(r1)+ + add r0,r2 + mov (r4)+,r0 + mov r2,(r1)+ + mov r0,(r1)+ + add r0,r2 + mov (r4)+,(r1)+ + mov r2,(r1)+ + mov offset,(r1) + add (r1)+,r2 + mov r2,(r1)+ + mov offset+2,(r1) + add (r1)+,r2 + mov (r4)+,r0 + mov r2,(r1)+ + mov r0,(r1)+ + mov (r4)+,r0 + cmp r0,hitext + blo 1f + mov r0,hitext +1: + mov (r4)+,ession + tst (r4)+ + beq 1f + jsr r5,errout + err2; .even + rts r5 +1: + tst (r5)+ + rts r5 + +doformaterr: + jsr r5,errout + err1; .even + jmp onerr + +/ handle switches +dosw: + mov (r1),r0 + movb 1(r0),r0 + cmpb r0,$'u + beq dosw_u + cmpb r0,$'l + beq dosw_l + cmpb r0,$'x + beq dosw_x + cmpb r0,$'e + beq dosw_e + cmpb r0,$'r + beq dosw_r + cmpb r0,$'s + beq dosw_s + rts r5 + +dosw_s: + inc sflag + inc nflag + rts r5 + +dosw_r: + clr rflag + rts r5 + +dosw_x: + inc nflag + rts r5 + +dosw_l: + movb $'a,libch + mov (r1),r1 + movb 2(r1),r0 + beq 1f + movb r0,libch +1: + mov $entry, at argv + tst (r5)+ + rts r5 + +dosw_e: + clr r4 + jsr r5,dosw_u + mov (r4),ession + rts r5 + +dosw_u: + dec argc + blt done2 + add $2,argv + mov @argv,r0 + mov $sysname,r1 + mov $8.,-(sp) +1: + movb (r0)+,(r1)+ + beq 2f + dec (sp) + bgt 1b +2: + dec (sp) + ble 3f + clrb (r1)+ + br 2b +3: + tst (sp)+ + mov $' ,(r1)+ + clr (r1)+ + jsr r5,lookup + tst (r4) + bne done2 + jsr r5,newsym +done2: + rts r5 + +rdsymtab2: + mov hession,r0 + bic $177700,r0 + beq 1f + cmp r0,$5 + bhis 1f + asl r0 + add @reltab(r0),hession+2 +1: + rts r5 + +findslot: + mov $symlst,r4 + cmp r4,symend + bhis 1f + cmp (r4)+,r2 + beq 2f + tst (r4)+ + br findslot+4 +1: + jsr r5,errout + err7; .even + jmp onerr +2: + mov (r4),r4 + rts r5 + +/ open input file +doopen: + clr entpt + mov r0,0f + mov r0,outfd + mov infd,r0 + beq 1f + sys close +1: + sys open; 0:.=.+2; 0 + bec 1f + jsr r5,errout + err6; .even + rts r5 +1: + mov r0,infd + tst (r5)+ + rts r5 + +/ do final relocation +doreloc: + add offset,tsize + add offset+2,dsize + add offset+4,bsize + rts r5 + +/ error messages +outmsg: +ldmsg: +err1: <: Can't move output file\n\0> + .even +err2: + .even +err3: + .even +err4: + .even +err5: + .even +err6: + .even +rderr: + .even +ldcan: + .even +filerr: + .even +fmterr: + .even +err7: + .even +err8: + .even +libpth: +liba: +libd: + .even +resvd: 0:.=.+2 +magic: 407 + +.bss +tsize: .=.+2 +dsize: .=.+2 +bsize: .=.+2 +hitext: .=.+2 +offset: .=.+6 +argc: .=.+2 +argv: .=.+2 +outfd: .=.+2 +infd: .=.+2 +sflag: .=.+2 +rflag: .=.+2 +nflag: .=.+2 +endflg: .=.+2 +entpt: .=.+2 +errcnt: .=.+2 +ession: .=.+2 +outfn: .=.+14. +libch: .=.+2 +outtxt: .=.+2 +outdat: .=.+2 +outbss: .=.+2 +errch: .=.+2 +pass2txt: .=.+2 +bufptr: .=.+2 +symptr: .=.+2 +symend: .=.+2 +sysname: .=.+16. +hdrrd: .=.+34. +hession: .=.+12. +outbf: .=.+512. +txtbf: .=.+512. +datbf: .=.+512. +rdbf: .=.+512. +sdbf: .=.+512. +rtbf: .=.+512. +hdrbf: .=.+34. +hdrbf2: +outhdr: .=.+16. +symhdr: .=.+16. +reltab: .=.+10. +hashbuf: .=.+2048. +entry: .=.+14. +symlst: +symtab = symlst+1000. diff --git a/cmd/maki.s b/cmd/maki.s new file mode 100644 index 0000000..1bd8907 --- /dev/null +++ b/cmd/maki.s @@ -0,0 +1,68 @@ +/ maki -- copy tape to disk (tape make) + + br start + bne 1f + 0 + 0 + 0 + 0 + 0 + 0 + +start: + sys open; src; 0 + bes error + mov r0,r1 + sys read; buf; 512. + mov r1,r0 + sys close + sys open; dst; 1 + bes error + mov r0,r1 + sys write; buf; 512. + bes error + sys open; rf0; 0 + bes error + mov r0,r2 + jsr pc,copy + mov r1,r0 + sys close + sys open; dst2; 1 + bes error + mov r0,r1 + jsr pc,copy + sys exit + +copy: + mov $512.,-(sp) +1: + mov r2,r0 + sys read; buf; 512. + bes error + mov r1,r0 + sys write; buf; 512. + bes error + dec (sp) + bne 1b + tst (sp)+ + rts pc + +error: + mov $1,r0 + sys write; errmsg; 16. + sys exit + +errmsg: + .even + +src: + .even +dst: + .even +rf0: + .even +dst2: + .even + +.bss +buf: .=.+512. diff --git a/cmd/mv.s b/cmd/mv.s new file mode 100644 index 0000000..7bd81b3 --- /dev/null +++ b/cmd/mv.s @@ -0,0 +1,157 @@ +/ mv -- move/rename files + + mov (sp)+,r2 + tst (sp)+ + cmp r2,$2 + blt badcount + mov (sp),r4 + cmpb (r4)+,$'- + bne 1f + cmpb (r4),$'d + bne 1f + tst (sp)+ + dec r2 + incb dflag +1: + cmp r2,$3 + beq 2f +badcount: + jsr r5,error + + .even +2: + mov (sp)+,r3 + mov (sp)+,r4 + mov r3,0f + sys stat; 0:..; sstbuf + bes noexit + jsr r5,error + + .even +noexit: + mov sstbuf+8.,mq + mov sstbuf+6.,ac + bit $40000,sstbuf+4 + bne destdir + mov r4,0f + sys stat; 0:..; dstbuf + bes samename + jsr r5,error + + .even +samename: + mov r3,r0 + mov r4,r1 +1: + cmpb (r0),(r1) + bne 2f + inc r0 + tstb (r1)+ + bne 1b + sys exit +2: + tstb (r0) + beq gotbase + cmpb (r0)+,$'/ + bne 2b + br 1b+4 + +gotbase: + tstb (r1) + beq dolink + cmpb (r1)+,$'/ + bne gotbase + jsr r5,error + + .even +dolink: + cmpb -(r0),$'. + bne trylink + jsr r5,error + + .even +trylink: + br link + +destdir: + sys setuid + sys getuid + mov r4,0f + sys stat; 0:..; dstbuf + bes link + bit $40000,dstbuf+4 + beq checkid + mov $nch,r1 +1: + movb (r4)+,(r1)+ + bne 1b + movb $'/,-1(r1) + mov r3,r4 + mov r3,r0 +1: + tstb (r4) + beq 2f + cmpb (r4)+,$'/ + bne 1b + mov r4,r0 + br 1b +2: + movb (r0)+,(r1)+ + bne 2b + mov $nch,r4 + br destdir + +checkid: + cmp sstbuf+2,dstbuf+2 + bne delold + jsr r5,error + + .even +delold: + mov r4,0f + sys unlink; 0:.. + bec link + jsr r5,error + + .even +link: + mov r3,0f + mov r4,0f+2 + sys link; 0:..; 0:.. + bec unl + jsr r5,error + + .even +unl: + mov r3,0f + sys unlink; 0:.. + bec date + jsr r5,error + + .even +date: + tstb dflag + beq done + mov r4,0f + sys smdate; 0:.. + bec done + jsr r5,error + + .even +done: + sys exit + +error: + movb (r5)+,ch + beq 1f + mov $1,r0 + sys write; ch; 1 + br error +1: + sys exit + +ch: .=.+2 +dflag: .=.+2 +sstbuf: .=.+40. +dstbuf: .=.+40. +nch: .=.+128. diff --git a/cmd/nm.s b/cmd/nm.s new file mode 100644 index 0000000..07cc47d --- /dev/null +++ b/cmd/nm.s @@ -0,0 +1,211 @@ +/ nm -- print symbol table + + cmp (sp)+,$2 + blt 1f + tst (sp)+ + mov (sp)+,0f +1: + sys open; 0:..; 0 + bes error + mov r0,r1 + sys read; hdr; 16. + cmp r0,$16. + bne error + cmp hdr,$432 + beq oldstyle + cmp hdr,$407 + bne error + mov hdr+6.,symsize + mov hdr+2,0f + br 1f + +oldstyle: + mov hdr+2,r2 + add hdr+6.,r2 + cmp hdr+14.,$1 + beq 1f + asl r2 +1: + add $16.,r2 + mov r2,0f + mov r1,r0 + sys seek; 0:..; 0 + add symsize,0f + sys seek; 0f+2; 0 + mov r1,r0 + sys read; syms; 0:.. + mov $syms,r1 + mov r1,r2 + add r0,r2 + mov r2,-(sp) + mov $12.,r3 + jsr pc,sort + mov (sp)+,r4 + mov $syms,r1 + br loop +error: + mov $1,r0 + sys write; errmsg; 2 + sys exit + +loop: + cmp r1,r4 + bcc done + mov $line,r2 + mov 8.(r1),r3 + mov r3,r5 + bic $177740,r3 + bne prval + mov $6,r3 +1: + movb $' ,(r2)+ + dec r3 + bne 1b + br prtype + +prval: + mov 10.(r1),num + clr num-2 + mov $6,r3 + mov $1,lsh + br 1f +2: + clr num-2 + mov $3,lsh +1: + add $'0,num-2 + movb num-2,(r2)+ + dec r3 + bne 2b + +prtype: + mov r1,-(sp) + mov r5,r3 + bic $40,r3 + cmp r3,$5 + blo 1f + mov $1,r3 +1: + movb types(r3),(r2)+ + movb $' ,(r2)+ + mov $8.,r3 + bit $40,r5 + beq 1f + movb $'_,(r2)+ + movb $'\b,(r2)+ +1: + movb (r1)+,(r2)+ + beq 2f + dec r3 + bne 1b +2: + movb $'\n,(r2)+ + sub $line,r2 + mov r2,0f + mov $1,r0 + sys write; line; 0:.. + mov (sp)+,r1 + add $12.,r1 + br loop + +done: + sys exit + +0: + .even +types: + .even + +sort: + mov r2,r0 + sub r1,r0 + cmp r0,r3 + ble sortdone + mov r0,num + mov r3,reclen + asr num + mov r3,num+2 + mov num,r4 + add r1,r4 +1: + mov r1,-(sp) + mov r2,-(sp) + mov r1,r0 + jsr pc,compare + bge 2f + add r3,r1 + br 1b +2: + cmp r2,r4 + blos 3f + sub r3,r2 + mov r2,r0 + jsr pc,compare + bge 2b + jsr pc,swap + cmp r1,r4 + bne 1b + mov r2,r4 + br 1b +3: + cmp r1,r4 + beq 4f + jsr pc,swap + mov r1,r4 + br 2b +4: + mov (sp)+,r2 + mov r4,-(sp) + mov r4,r1 + add r3,r1 + jsr pc,sort + mov (sp)+,r2 + mov (sp)+,r1 + br sort +sortdone: + rts pc + +compare: + mov r3,-(sp) + mov r4,-(sp) +1: + cmpb (r0)+,(r4)+ + bne 2f + dec r3 + bne 1b + clr r0 + br 3f +2: + blo 4f + mov $1,r0 + br 3f +4: + mov $-1,r0 +3: + mov (sp)+,r4 + mov (sp)+,r3 + tst r0 + rts pc + +swap: + mov r1,-(sp) + mov r2,-(sp) + mov r3,-(sp) +1: + movb (r1),r0 + movb (r2),(r1)+ + movb r0,(r2)+ + dec r3 + bne 1b + mov (sp)+,r3 + mov (sp)+,r2 + mov (sp)+,r1 + rts pc + +errmsg: +hdr: .=.+16. +symsize: .=.+2 +num: .=.+4 +reclen: .=.+2 +line: .=.+40. +syms: diff --git a/cmd/od.s b/cmd/od.s new file mode 100644 index 0000000..fbeae73 --- /dev/null +++ b/cmd/od.s @@ -0,0 +1,112 @@ +/ od -- octal dump + + sys break; end + mov (sp)+,r1 + tst (sp)+ + cmp r1,$2 + blt error + mov (sp)+,0f + sys open; 0:..; 0 + bes error + mov r0,fin + cmp r1,$2 + ble 1f + mov (sp)+,r0 +2: + movb (r0)+,r1 + beq 1f + asl offset + asl offset + asl offset + bic $177770,r1 + bis r1,offset + br 2b +1: + bic $7,offset + cmp addr,offset + beq loop + jsr pc,getw + br 1b + +loop: + mov addr,r0 + jsr pc,praddr + mov $8.,r1 + mov $' ,r0 + jsr pc,putc +1: + jsr pc,getw + mov r0,-(sp) + blt 2f + mov $' ,r0 + jsr pc,putc + br 3f +2: + mov $'-,r0 + jsr pc,putc +3: + mov (sp)+,r0 + jsr pc,praddr + dec r1 + bne 1b + mov $'\n,r0 + jsr pc,putc + br loop + +error: + mov $1,r0 + sys write; errmsg; 4 + sys exit + +errmsg: + +getw: + bne 1f + cmp bufp,$buf+512. + bne 2f + mov fin,r0 + sys read; buf; 512. + bes error + tst r0 + beq done + mov $buf,bufp +2: + mov @bufp,r0 + add $2,bufp + rts pc + +done: + mov $1,r0 + sys write; nl; 1 + sys exit +nl: <\n> + +praddr: + mov r0,mq + inc lsh + mov $5,-(sp) +1: + clr ac + mov $3,lsh + mov ac,r0 + add $'0,r0 + jsr pc,putc + dec (sp) + bne 1b + tst (sp)+ + rts pc + +putc: + mov r0,ch + mov $1,r0 + sys write; ch; 1 + rts pc + +ch: .=.+2 +offset: .=.+2 +addr: buf+512. +fin: .=.+2 + +buf: .=.+512. +bufp: .=.+2 +end: diff --git a/cmd/pr.s b/cmd/pr.s new file mode 100644 index 0000000..15cc545 --- /dev/null +++ b/cmd/pr.s @@ -0,0 +1,342 @@ +/ pr -- print/paginate files + + sys break; end + mov (sp)+,nfiles + tst (sp)+ + clr r0 + sys fstat; stbuf + bit $1,stbuf+4 + beq loop + sys gtty; ttybuf + mov ttybuf,r0 + sub stbuf+4,r0 + add $'0,r0 + movb r0,ttyno + sys stty; ttybuf; 14 + bes 1f + inc ttyflg +1: +loop: + clr fin + mov fin,r0 + beq 1f + sys close + clr fin +1: + dec nfiles + bgt 2f + jmp done +2: + mov (sp)+,r0 + mov r0,filnam + cmpb (r0)+,$'- + bne dofile + cmpb (r0),$'l + bne 3f + mov $78.,linesz + br loop +3: + cmpb (r0),$'r + bne 4f + mov $66.,linesz + br loop +4: + cmpb (r0),$'m + bne 5f + clr cflag + br loop +5: + cmpb (r0),$'c + bne dofile + inc cflag + br loop + +dofile: + mov filnam,r0 + jsr r5,fopen; buf + bes loop + tst cflag + beq 2f + sys fstat + mov mq,fmtime + mov ac,fmtime+2 + br 3f +2: + mov fin,r0 + sys fstat; stbuf + mov stbuf+32.,fmtime + mov stbuf+30.,fmtime+2 +3: + clr pageno + clr eof + clr pushc + +page: + jsr pc,header + br loop + +error: + mov $1,r0 + sys write; errmsg; 2 + mov $1,r0 + mov fmtime,mq + mov fmtime+2,ac + jsr pc,prdate + mov $1,r0 + sys write; errmsg+2; 2 + inc pageno + mov filnam,r1 + mov r1,0f + mov $-1,r0 +1: + inc r0 + tstb (r1)+ + bne 1b + mov r0,0f+2 + mov $1,r0 + sys write; 0:..; 0:.. + mov $1,r0 + sys write; sp2; 6 + mov pageno,mq + jsr pc,prpage + mov $1,r0 + sys write; nl; 4 + mov linesz,r1 + sub $11.,r1 +body: + jsr pc,prbody +1: + jsr pc,getc + cmp r0,$'\n + bne 1b + dec r1 + bne 1b + mov $1,r0 + sys write; nl; 5 + br page + +done: + tst ttyflg + beq 1f + sys stty; ttybuf; 15 +1: + sys exit + +prpage: + clr ac + mov $10.,div + mov ac,-(sp) + tst mq + beq 1f + jsr pc,prpage +1: + mov (sp)+,r0 + add $'0,r0 + mov r0,ch + mov $1,r0 + sys write; ch; 1 + mov ch,r0 + rts pc + +prbody: + mov pushc,r0 + beq 1f + clr pushc + rts pc +1: + tst eof + beq 2f + mov $'\n,r0 + rts pc +2: + jsr r5,getc; buf + bec 3f + mov pc,eof + br prbody +3: + rts pc + +header: + jsr pc,prbody + mov r0,pushc + tst eof + bne 1f + add $2,(sp) +1: + rts pc + +nl: + <\n\n > +sp2: < Page \0> + .even +tty: + .even + +linesz: 66. +fmtime: .=.+4 +nfiles: .=.+2 +eof: .=.+2 +pushc: .=.+2 +ch: .=.+2 +fin: .=.+2 +stbuf: .=.+40. +filnam: .=.+2 +cflag: .=.+2 +ttyflg: .=.+2 +ttybuf: .=.+6 +ttyno = tty+8. +pageno: .=.+2 + +prdate: + mov r1,-(sp) + sub $16.,sp + mov r0,r1 + mov sp,r0 + jsr pc,fmtdate + mov r0,0f + mov r1,r0 + sys write; 0:..; 17. + add $16.,sp + mov (sp)+,r1 + rts pc + +fmtdate: + mov r2,-(sp) + mov r3,-(sp) + cmp ac,yrdays + blo 1f + bhi 2f + cmp mq,yrdays+2 + blo 1f +2: + mov ac,-(sp) + sub yrdays+2,mq + sbc (sp) + sub yrdays,(sp) + mov (sp)+,ac + mov $29.,daylen +1: + mov $-4,lsh + mov $26300.,div + mov mq,r3 + mov ac,mq + mov $2,lsh + mov $17.,div + add $17.,r0 + jsr r5,digit; 10. + jsr r5,digit; 6 + movb $':,-(r0) + jsr r5,digit; 10. + jsr r5,digit; 6 + movb $':,-(r0) + mov r3,mq + mov $24.,div + mov mq,r3 + mov ac,mq + jsr r5,digit; 10. + jsr r5,digit; 10. + mov r2,$montab +1: + cmp (r2),r3 + bgt 2f + sub (r2)+,r3 + br 1b +2: + movb $' ,-(r0) + sub $montab,r2 + asl r2 + add $months,r2 + inc r3 + mov r3,mq + jsr r5,digit; 10. + tst mq + beq 1f + add $'0,mq + movb mq,-(r0) + br 2f +1: + movb $' ,-(r0) +2: + movb $' ,-(r0) + movb -(r2),-(r0) + movb -(r2),-(r0) + movb -(r2),-(r0) + mov (sp)+,r3 + mov (sp)+,r2 + rts pc + +digit: + clr ac + mov (r5)+,div + add $'0,ac + movb ac,-(r0) + rts r5 + +yrdays: 57544.; 4480. +daylen: 31.; 28.; 31.; 30.; 31.; 30.; 31.; 31.; 30.; 31.; 30. +montab = .-2 +months: + < \0Jan\0Feb\0Mar\0Apr\0May\0Jun\0Jul\0Aug\0Sep\0Oct\0Nov\0Dec\0> + .even + +fopen: + mov r1,-(sp) + mov (r5)+,r1 + mov r0,0f + sys open; 0:..; 0 + bec 1f + mov $-1,(r1) + mov (sp)+,r1 + sec + rts r5 +1: + mov r0,(r1)+ + clr (r1)+ + mov (sp)+,r1 + rts r5 + +getword: + mov (r5),0f + mov (r5)+,0f+2 + jsr r5,getc; 0:.. + bec 1f + rts r5 +1: + mov r0,-(sp) + jsr r5,getc; 0:.. + swab r0 + bis (sp)+,r0 + rts r5 + +getc: + mov r1,-(sp) + mov (r5)+,r1 + dec 2(r1) + bge 2f + mov r1,r0 + add $6,r0 + mov r0,0f + mov r0,4(r1) + mov (r1),r0 + sys read; 0:..; 512. + bec 1f +1: + tst r0 + bne 3f + mov (sp)+,r1 + sec + rts r5 +3: + dec r0 + mov r0,2(r1) +2: + clr r0 + bisb @4(r1),r0 + inc 4(r1) + mov (sp)+,r1 + rts r5 + +errmsg: + +buf: .=.+518. +end: diff --git a/cmd/roff.s b/cmd/roff.s new file mode 100644 index 0000000..6b071f4 --- /dev/null +++ b/cmd/roff.s @@ -0,0 +1,1025 @@ +/ roff -- text formatter + + cmp sp,$57544 + bhi 1f + jsr r5,memerr + ; .even + sys exit +1: + clr r0 + jsr pc,init + sys exit + br done + +/ stack check and initialization +start: + clr r0 + jsr pc,init + sys creat; fname; 17 + bes error + mov r0,outfd + tst (sp)+ + mov (sp)+,0f +1: + mov $buf,r4 + jsr r5,descend + cmp r4,$buf + beq 2f + jsr pc,flush + br 1b +2: + mov $1,r0 + sys write; header+1; 3 + mov outfd,r0 + beq done + sys close + sys open; fname; 0 + bec 1f + br error +1: + mov r0,tmpfd + br done + +error: + mov $1,r0 + sys write; errmsg; 5 + sys exit + +done: + tst outfd + beq 1f + sys creat; 0:..; 17 + bec 1f + br error +1: + sys open; dfile; 0 + bes error + mov r0,dfd + +/ main processing loop +loop: + clr nlines + jsr pc,getchar + cmpb r0,escchar + beq command + movb r0,savec + jsr pc,text + br loop + +/ command processor +command: + jsr pc,getchar + mov r0,-(sp) + jsr pc,getchar + swab r0 + bis (sp),r0 + mov $cmdtab,r1 +1: + mov (r1)+,(sp) + bic $100000,(sp) + cmp r0,(sp) + bne 2f + mov (r1),(sp) + tst -(r1) + bpl 3f + jsr pc,skipl + cmp bptr,$bufend + bgt 4f + mov reqaddr, at bptr + add $2,bptr + mov (sp),reqaddr + br 4f +3: + jmp @(sp)+ +2: + cmp (r1)+,$-1 + bne 1b +4: + tst (sp)+ + rts pc + +/ command table +cmdtab: + ; adjcmd + ; bpcmd +
; brcmd + ; cccmd + ; cecmd + ; dscmd + ; ficmd + ; incmd + ; ixcmd +
  • ; licmd + ; llcmd + ; lscmd + ; nacmd + ; necmd + ; nfcmd + ; pacmd + ; plcmd + ; skcmd + ; spcmd + ; sscmd + ; tacmd + ; ticmd + ; trcmd +
      ; ulcmd + ; uncmd + ; hecmd + ; hxcmd + ; focmd + ; ehcmd + ; ohcmd + ; efcmd + ; ofcmd + ; m1cmd + ; m2cmd + ; m3cmd + ; m4cmd + ; hccmd + ; hycmd + ; n1cmd + ; n2cmd + ; nncmd + ; nicmd + ; jocmd + ; arcmd + ; rocmd + ; nxcmd + ; pocmd + ; decmd + ; igcmd + ; tccmd + ; mkcmd + -1; -1 + +/ various command routines + +adjcmd: + jsr pc,skipl + inc adj + rts pc + +bpcmd: + jsr pc,skipl + jsr r5,getnum + 0 + jsr pc,eject + rts pc + +brcmd: + jsr pc,brk + rts pc + +cccmd: + jsr pc,getch + jsr pc,getchar + cmp r0,$'\n + beq 1f + movb r0,escchar +1: + rts pc + +cecmd: + jsr pc,skipl + jsr r5,getnum + cenline + jsr pc,eject + mov r0,cenline + rts pc + +ficmd: + jsr pc,skipl + inc fill + rts pc + +incmd: + jsr pc,skipl + jsr pc,getch + jsr pc,getchar + cmp r0,$'\n + beq 1f + mov inset,inset2 + rts pc +1: + mov r0,savec + jsr r5,getnum + inset + dec r0 + jsr pc,eject + inc r0 + mov r0,inset + mov r0,inset2 + rts pc + +nacmd: + jsr pc,skipl + clr adj + rts pc + +nfcmd: + jsr pc,skipl + clr fill + rts pc + +llcmd: + jsr pc,skipl + jsr pc,eject + jsr pc,getch + tst nlines + bne 1f + jsr r5,getnum + linelen + jsr pc,eject + mov r0,linelen +1: + rts pc + +plcmd: + jsr pc,skipl + jsr r5,getnum + 0 + jsr pc,eject + mov r0,plen + mov r0,plen2 + rts pc + +spcmd: + jsr r5,getnum + 0 + mov r0,spbef + jsr pc,init2 + rts pc + +sscmd: + jsr r5,getnum + 0 + mov r0,spaft + rts pc + +tacmd: + mov $tabs,r1 + jsr r5,getnum + 0 +1: + jsr pc,eject + dec r0 + ble 2f + movb r0,(r1)+ + br 1b +2: + clrb (r1)+ + rts pc + +ticmd: + jsr pc,skipl + jsr r5,getnum + tind + jsr pc,eject + mov r0,plen2 + rts pc + +trcmd: + jsr r5,getnum + 0 + jsr pc,eject + mov r0,trlim + rts pc + +ulcmd: + tst ulflag + bne 1f + clr ulflag + br 2f +1: + inc ulflag +2: + jsr pc,init2 + rts pc + +/ header/footer commands + +hecmd: + jsr r5,hfset + htitle + mov htitle,htitle2 + mov htitle,htitle3 + rts pc + +hxcmd: + jsr r5,hfset + htitle + rts pc + +focmd: + jsr r5,hfset + ftitle + rts pc + +ehcmd: + jsr r5,hfset + htitle + rts pc + +ohcmd: + jsr r5,hfset + htitle2 + rts pc + +efcmd: + jsr r5,hfset + ftitle + rts pc + +ofcmd: + jsr r5,hfset + ftitle2 + rts pc + +m1cmd: + jsr r5,getnum + 0 + mov r0,m1 + br mend +m2cmd: + jsr r5,getnum + 0 + mov r0,m2 + br mend +m3cmd: + jsr r5,getnum + 0 + mov r0,m3 + br mend +m4cmd: + jsr r5,getnum + 0 + mov r0,m4 +mend: + jsr pc,init2 + rts pc + +/ margin and number commands + +pocmd: + jsr pc,getch + jsr pc,getchar + cmp r0,$'\n + beq 1f + mov r0,r1 + jsr pc,getchar + cmp r0,$'\n + bne 2f + mov $' ,r0 +2: + movb r0,trtab(r1) + br pocmd +1: + rts pc + +n1cmd: + jsr pc,skipl + mov $1,nummode + br numset + +n2cmd: + jsr pc,skipl + mov $2,nummode +numset: + clr numcnt + jsr r5,getnum + 0 +1: + tst r0 + ble 2f + mov r0,nummax + rts pc +2: + clr nummode + rts pc + +nncmd: + jsr r5,getnum + 0 + mov r0,numcnt + rts pc + +nicmd: + jsr r5,getnum + nind + jsr pc,eject + mov r0,nind + rts pc + +/ text processing routines + +text: + clr wrdflag + clr nwords + clr nchars + clr hypflag + mov $outbuf,wptr + clr -(sp) + jsr pc,gchar + cmp r0,$'\n + beq txtend + cmp r0,hypchar + bne 1f + inc hypflag + br 2b +1: + cmp $' ,r0 + bne 3f + jsr pc,putsp + br 2b +3: + mov r0,-(sp) + mov $' ,r0 + jsr pc,putsp + tst dotflag + beq 4f + jsr pc,putsp + clr dotflag +4: + mov (sp)+,r0 + jsr pc,putch + bisb r0, at lastch + clr (sp) + jsr pc,gchar + cmp r0,hypchar + bne 5f + inc hypflag + jsr pc,gchar + mov $200,(sp) +5: + cmp $' ,r0 + beq 6f + cmp $'\n,r0 + bne 4b + cmpb -1(wptr),$'. + bne 6f + inc dotflag +6: + add $2,2(sp) + clrb (wptr)+ +txtend: + tst (sp)+ + mov $outbuf,wptr + tst nwords + bne 1f + jsr pc,1f +1: + rts pc + +/ output routines + +putch: + cmp wptr,$bufend + bcc 1f + movb r0, at wptr + inc wptr + jsr pc,charwid + add r1,cwid + sub r1,remain + inc nchars +1: + rts pc + +putsp: + mov $outbuf,r2 + clr nspaces + clr nwords +1: + movb (r2)+,r0 + cmp $' ,r0 + bne 2f + jsr pc,space + tst nwords + bne 1b + br 3f +2: + jsr pc,emit + dec nchars + bgt 1b +3: + jsr pc,newln + clr nspaces + clr cwid + mov linelen,remain + mov inset,wptr + rts pc + +space: + inc nspaces + tst adj + beq 1f + inc extrasp + cmp extrasp,nspaces + blt 2f + inc r0 +2: + jsr pc,emit +1: + rts pc + +emit: + movb r0, at optr + inc optr + cmp optr,$obufend + blo 1f + mov outfd,r0 + sys write; obuf; 512. + mov $obuf,optr +1: + rts pc + +newln: + mov $'\n,r0 + jsr pc,emit + inc lineno + rts pc + +brk: + tst splen + beq 1f + clrb @optr + inc pageno +1: + jsr pc,flush2 + rts pc + +eject: + tst splen + beq 1f + sub lineno,r0 + neg r0 + jsr pc,eject2 + mov r0,plen2 + tst nummode + beq 1f + add $2,plen2 +1: + clr extrasp + clr wrdspc + mov $1000,nspaces + mov $' ,r0 + jsr pc,putch + jsr pc,skipl + dec trlim + bpl 2f + clr trlim +2: + rts pc + +/ number output routines + +prnum: + mov r0,mq +1: + clr ac + mov $10.,div + mov ac,-(sp) + tst mq + beq 2f + jsr pc,1b +2: + mov (sp)+,mq + add $'0,mq + mov outfd,r0 + sys write; mq; 1 + rts pc + +/ character width table +charwid: + cmp r0,hypchar + beq 2f + tst r0 + beq 2f + cmp r0,$177 + beq 2f + cmp r0,$'\b + bne 1f + mov $-1,r1 + rts pc +1: + cmp $' ,r0 + bgt 2f + mov $1,r1 + rts pc +2: + clr r1 + rts pc + +/ get character, handling escapes +getchar: + mov savec,r0 + beq 1f + clr savec + rts pc +1: + tst nlines + bne 2f + mov $'\n,r0 + rts pc +2: + jsr pc,getch + cmp r0,$'\\ + bne 3f + jsr pc,getch + jsr r5,escmap + esctab + br 4f +3: + cmp r0,$'\e + bne 4f + jsr pc,getch + jsr r5,escmap + esctab2 +4: + cmp r0,$'\n + bne 5f + inc nlines + clr colno +5: + mov r1,-(sp) + jsr pc,charwid + add r1,colno + mov (sp)+,r1 + rts pc + +/ escape character mapping +escmap: + mov r1,-(sp) + mov (r5)+,r1 +1: + cmpb (r1)+,r0 + beq 2f + tstb (r1)+ + bne 1b + cmp r1,$esctab2 + ble 3f + cmp r1,$esctab2e + bgt 3f + mov $37,r0 +3: + mov (sp)+,r1 + rts r5 +2: + movb (r1)+,r0 + mov (sp)+,r1 + rts r5 + +/ escape tables +esctab: + <-\210\0n\012\0t\011\0\\\\134\0>\0\0> + .even +esctab2: + <0\260\0-\304\0'\222\0`\223\0>\0\0> + .even +esctab2e: + +/ getch from buffer or file +getch: + tst bcount + ble 1f + dec bcount + mov inptr,r0 + rts pc +1: + mov r1,-(sp) + tst reqaddr + bne 2f + jsr pc,readblk + br 3f +2: + tst fildes + bne 4f + mov fptr,r1 + cmp r1,fend + bne 5f +4: + mov fname,r0 + bne 6f + jsr pc,open1 +6: + clr fildes + sys read; inbuf; 512. + bes done + tst r0 + beq done + mov $inbuf,r1 + add r0,r1 + mov r1,fend +5: + movb (r1)+,r0 + mov r1,fptr + cmp r0,$'\t + bne 3f + mov (sp)+,r1 + mov $tabs,r0 + inc bcount + tstb (r0) + beq getch + cmpb colno,(r0)+ + bge 8f + movb -(r0),bcount + sub colno,bcount + br getch +8: + br 3f+2 +3: + br 7f +7: + tst r0 + beq 2b + mov (sp)+,r1 + rts pc + +/ open file for input +open1: + mov fname,r0 + bne 1f + sys close +1: + tst fildes + beq 2f + mov $defout,1f + br 3f +2: + dec nfiles + blt done + mov @fnames,1f + add $2,fnames +3: + sys open; 1:..; 0 + bes error + mov r0,fname + rts pc + +/ flush output buffer +flush: + inc nameloc + tst outfd + beq 1f + movb r0,(r4)+ + cmp r4,$buf+512. + blo 1f + mov outfd,r0 + sys write; buf; 512. + mov $buf,r4 +1: + rts pc + +flush2: + mov optr,r0 + sub $obuf,r0 + mov r0,0f + mov $1,r0 + sys write; obuf; 0:.. + mov $obuf,optr + rts pc + +/ initialization +init: + mov $obuf,optr + jsr pc,init2 + sys exit + +init2: + mov splen,r0 + bne 1f + clr plen2 + rts pc +1: + sub m3,r0 + sub m4,r0 + sub ulflag,r0 + mov r0,plen2 + mov linelen,r0 + add m1,r0 + add m2,r0 + add ulflag,r0 + cmp r0,plen2 + blt 2f + mov $2,r0 + mov r0,m1 + mov r0,m2 + mov r0,m3 + mov r0,m4 + mov $102.,splen + br init2 +2: + cmp lineno,plen2 + ble 3f + mov plen2,lineno +3: + rts pc + +/ get a number argument +getnum: + jsr pc,getch + mov r1,-(sp) + clr mq + clr -(sp) + clr -(sp) + jsr pc,getchar + cmp r0,$'+ + beq 1f + cmp r0,$'- + beq 1f + sub $'0,r0 + cmp r0,$9. + bhi 2f + inc (sp) + mov $10.,mul + add r0,mq + br getnum+4 +1: + mov r0,2(sp) + br getnum+4 +2: + add $'0,r0 + mov r0,savec + mov (sp)+,r0 + bne 3f + mov $1,mq + mov mq,r0 +3: + mov (r5)+,r0 + beq 4f + mov (r0),r0 +4: + mov (sp)+,r1 + cmp r1,$'- + bne 5f + sub mq,r0 + br 6f +5: + cmp r1,$'+ + bne 7f + add mq,r0 + br 6f +7: + mov mq,r0 +6: + mov (sp)+,r1 + rts r5 + +/ header/footer setup +hfset: + jsr pc,getch + mov r1,-(sp) + mov (r5)+,r1 + mov r1,@(r5)+ + jsr pc,gchar + cmp r0,$'\n + beq 3f + mov r0,r2 + jsr pc,gchar + cmp r0,$'\n + beq 3f + cmp r0,r2 + bne 2f + clr r0 +2: + jsr pc,wrchar + br 1b +3: + clr r0 + jsr pc,wrchar + mov r1,hfptr + mov linelen,hflen + rts r5 + +wrchar: + mov r0,char + mov 1f,r0 + mov reqaddr,r1 + sys seek; 0:..; 0 + mov reqaddr,r0 + sys write; char; 1 + inc r1 + cmp reqaddr,reqmax + bne 1f + mov $-1,reqmax +1: + rts pc + +/ skip to end of line +skipl: + jsr pc,getchar + cmp r0,$'\n + bne skipl + rts pc + +/ hyphenation support +hyphen: + tst hypflag + bne 1f + tst hyflag + beq 1f + inc hypflag + mov wptr,r0 + clr nwords +1: + rts pc + +/ data area +defout: + .even +suftab: + .even +tmpfil: + .even + +reqmax: -1; 4 +reqaddr: 0 +fptr: 0 +fend: 0 +fildes: 0 +fname: 0 +outfd: 0 +tmpfd: 0 +dfd: 0 +optr: 0 +wptr: 0 +bptr: 0 +bufend: 0 +obufend: 0 +inptr: 0 +bcount: 0 +nfiles: 0 +fnames: 0 +nameloc: 0 + +/ formatting parameters +escchar: '. +hypchar: '- +fill: 1 +adj: 0 +nlines: 0 +colno: 0 +savec: 0 +char: 0 + +linelen: 65. +inset: 0 +inset2: 0 +tind: 0 +plen: 66. +plen2: 66. +splen: 0 +spbef: 0 +spaft: 0 +trlim: 0 +cenline: 0 +ulflag: 0 +hypflag: 0 +dotflag: 0 +wrdflag: 0 + +lineno: 0 +pageno: 0 +nspaces: 0 +extrasp: 0 +nchars: 0 +nwords: 0 +cwid: 0 +remain: 65. +wrdspc: 0 +lastch: 0 + +/ margin parameters +m1: 2 +m2: 2 +m3: 2 +m4: 2 + +/ numbering parameters +nummode: 0 +numcnt: 0 +nummax: 0 +nind: 5 + +/ title storage +htitle: 0 +htitle2: 0 +htitle3: 0 +ftitle: 0 +ftitle2: 0 +hfptr: 0 +hflen: 0 + +/ character translation table +trtab: .=.+256. + +/ tab settings +tabs: .=.+32. + +/ buffers +obuf: .=.+512. +inbuf: .=.+512. +outbuf: .=.+512. +buf: .=.+512. + +errmsg: diff --git a/cmd/size.s b/cmd/size.s new file mode 100644 index 0000000..7e6897e --- /dev/null +++ b/cmd/size.s @@ -0,0 +1,762 @@ +/ size -- print section sizes (B language program) + + br start + blt regs + 0 + 0 + 0 + 0 + 0 + 1 + +/ threaded interpreter startup +start: + mov $mq,r3 + mov sp,r0 + mov (sp),-(sp) + tst (r0)+ + mov r0,2(sp) + mov 60.,-(sp) + mov $tbl,r5 + jmp @(r5)+ + +/ tables and data +tbl: + bic (r5)+,r0 + 0 +lbl1: + bic r0,@(sp)+ + sys exit +lbl2: + bic r0,-(r2) + bic (r5)+, at -(r0) + 18. + bic (r5)+,-(r0) + 26. + bic (r3)+,-8.(r0) + bic (r3)+, at -(r0) + 4 + bic (r7),(sp)+ + bic (r3)+, at -(r0) + -24. + bic (r4)+,r4 + 1 + bic (r7), at outbf(r0) + bic r1,@(r0)+ + bic (r3)+, at -(r0) + 6 + bic (r4)+,r4 + bic r6,(r2) + bic (r7),(sp)+ + bic (r3)+,-24.(r0) + bic (r2)+,(r4)+ + bic (r3)+,6(r0) + bic (r2)+, at outbf(sp) + -24. + bic (r2)+, at -(r0) + bic (r5)+,outbf+4(sp) + bic (r3)+,6(r0) + bic (r2)+,-(r2) + bic (r3)+,-22.(r0) + bic (r4)+,r4 + 0 + bic (r3)+, at -(r0) + 6 + bic (r1)+,outbf(r4) + bic (r5),-(r4) + bic (r4)+, at -(r0) + 4 + bic (r7),@(r2)+ + bic (r4)+,r4 + 0 + bic (r0)+,(r0)+ + bic (r5)+,outbf+2(sp) + bic (r3)+, at -(r0) + 6 + bic (r1)+,outbf+4(r4) + bic (r4)+,r4 + bic r6,(r0)+ + bic (r4)+,r0 + bic (r0),(r2)+ + bic (r5)+,r0 + 4 + bic (r4)+,r0 + bic r6,@(sp)+ + bic (r5)+,@(r4)+ + bic (r4)+,r4 + 16. + bic (r3)+, at -(r0) + -20. + bic (r3)+, at -(r0) + -22. + bic (r4)+,r0 + bic (sp),4(r4) + bic (r5)+,r0 + 6 + bic (r3)+, at -(r0) + -20. + bic (r4)+,r4 + 0 + bic (r4)+,(sp) + bic (r4)+,r4 + br 1f + +1: + bic (r0)+,r0 + bic (r5)+,outbf+6(sp) + bic (r3)+, at -(r0) + 6 + bic (r1)+,outbf+4(r4) + bic (r4)+,r4 + bic r6,-(r0) + bic (r4)+,r0 + bic (r0),(r2)+ + bic (r5)+,r0 + 4 + bic (r3)+, at -(r0) + -22. + bic (r4)+,r0 + bic (r5),(r2)+ + bic (r5)+,r0 + 2 + bic (r4)+,r0 + bic r6,@(sp)+ + bic (r5)+,@(r4)+ + bic (r3)+, at -(r0) + 4 + bic (r4)+,r4 + 2 + bic (r0)+,-(r0) + bic (r5)+,outbf+16.(sp) + bic (r3)+, at -(r0) + 6 + bic (r1)+,outbf+4(r4) + bic (r4)+,r4 + bic r6,outbf(r0) + bic (r4)+,r0 + bic (r0),(r2)+ + bic (r5)+,r0 + 4 + bic (r3)+, at -(r0) + -20. + bic (r4)+,r4 + 3 + bic (r4)+,(sp) + bic (r3)+, at -(r0) + -20. + bic (r4)+,r4 + 2 + bic (r4)+,(sp) + bic (r3)+, at -(r0) + -20. + bic (r4)+,r4 + 1 + bic (r4)+,(sp) + bic (r4)+,r4 + bic r6,outbf(sp) + bic (r4)+,r0 + bic (r0),(r2)+ + bic (r5)+,r0 + 8. + bic (r3)+,-26.(r0) + bic (r3)+, at -(r0) + -20. + bic (r4)+,r4 + 1 + bic (r4)+,(sp) + bic (r3)+, at -(r0) + -20. + bic (r4)+,r4 + 2 + bic (r4)+,(sp) + bic (r1)+,r6 + bic (r3)+, at -(r0) + -20. + bic (r4)+,r4 + 3 + bic (r4)+,(sp) + bic (r1)+,r6 + bic (r7),(sp)+ + bic (r3)+,-26.(r0) + bic (r4)+,r4 + bic r7,r4 + bic (r4)+,r0 + bic (r0),(r2)+ + bic (r5)+,r0 + 4 + bic (r3)+, at -(r0) + -22. + bic (r4)+,r0 + bic (r5),(r0)+ + bic (r5)+,r0 + 2 + bic (r4)+,r0 + bic (r5),(r0)+ + bic (r5)+,@(r4)+ + bic (r3)+,-4(r0) + bic (r3)+, at -(r0) + -8.(r0) + bic (r7),(sp)+ + bic (r3)+,-10.(r0) + bic (r3)+,-4(r0) + bic (r3)+,r4 + bic (r1)+, at hession(r0) + bic (sp)+,r0 + bic (r4),@(r0)+ + bic (r3)+, at -(r0) + -8.(r0) + bic (r4)+,r4 + 0 + bic (r0)+,(r0)+ + bic (r5)+,hession+4(sp) + bic (r3)+, at -(r0) + -8.(r0) + bic (r3)+, at -(r0) + -8.(r0) + bic (r1)+,pD(r0) + bic (r7),(sp)+ + bic (r4)+,r4 + '- + bic (r4)+,r0 + bic (sp),r2 + bic (r5)+,r0 + 2 + bic (r3)+, at -(r0) + -10.(r0) + bic (r4)+,r4 + 'o + bic (r7), at outbf(r0) + bic (r2), at hession+2(r2) + bic (r4)+,r4 + 8. + bic (r5)+,hession+6(r2) + bic (r4)+,r4 + 10. + bic (r3)+, at -(r0) + -8.(r0) + bic (r4)+,r0 + bic r7,(r2) + bic (r5)+,r0 + 4 + bic (r4)+,r0 + bic (r5),(r0)+ + bic (r5)+,@(r4)+ + bic (r3)+, at -(r0) + -8.(r0) + bic (r4)+,r0 + bic (sp),r2 + bic (r5)+,r0 + 2 + bic (r4)+,r0 + bic (r5),(r0)+ + bic (r5)+,@(r4)+ + bic (r3)+,-4(r0) + bic (r3)+, at -(r0) + -8.(r0) + bic (r7),(sp)+ + bic (r3)+,-10.(r0) + bic (r3)+,-4(r0) + bic (r3)+,r4 + bic (r1)+, at hession(r0) + bic (r5)+,hession+16.(sp) + bic (r3)+, at -(r0) + -10.(r0) + bic (r4)+,r0 + bic (sp),r2 + bic (r5)+,r0 + 2 + bic (r5)+,hession+12.(r2) + bic (r4)+,r0 + bic (r5),(r0)+ + bic (r5)+,@(r4)+ + bic (r5)+,outbf+2(r2) + + jmp -(r4) + bic (r1),@'o(sp) + bic (r1),@'c(sp) + bic (r3),(r0)+ + jmp outbf+2(r3) + 0 + 0 + bic (r4)+,r4 + '% + bic (r4)+,r0 + bic (sp),r2 + bic (r5)+,r0 + 2 + bic (r3)+,4(r0) + bic (r2)+,outbf(r0) + -6.(r2) + bic (r2)+, at outbf(sp) + bic (r4)+,r0 + bic (r5),(r0)+ + bic (r5)+,@(r4)+ + bic (r5)+,-(r0) + 2 + bic (r5)+,@(r0)+ + +/ error strings +aoutmsg: + .even +notfnd: <%s not found\n\0> + .even +badfmt: + .even +sfmt: <%s: \0> + .even +ofmt: <%0o+%0o+%0o=\0> + .even +ofmt2: <%0o\n\0> + .even + +/ threaded interpreter primitives +tstart: + bic r7,(r4) + bic (r5)+,-(r0) + 4 + bic (r3)+,-4(r0) + bic (r3)+, at -(r0) + 4 + bic (r3)+, at -(r0) + 6 + bic (r1)+,-(r4) + bic (r7),@(r2)+ + bic (r5)+,outbf+14.(sp) + bic (r3)+, at -(r0) + 6 + bic (r3)+, at -(r0) + -4(r0) + bic (r4)+,r0 + bic r7,(r2) + bic (r5)+,r0 + 4 + bic (r3)+, at -(r0) + 4 + bic (r3)+, at -(r0) + 6 + bic (r1)+,(sp) + bic (r4)+,r4 + '0 + bic (r1)+,r6 + bic (r4)+,r0 + bic (sp),r2 + bic (r5)+,r0 + 2 + bic (r5)+,-(r0) + 2 + bic (r5)+,@(r0)+ + bic (r5)+,-(r0) + 10. + bic (r3)+,-6.(r0) + bic (r3)+,6(r0) + bic (r7),(sp)+ + bic (r5)+,-(r0) + 10. + bic (r3)+,-10.(r0) + bic (r3)+,4(r0) + bic (r3)+,r4 + bic (r1)+, at hession(r0) + bic (sp)+,hession+16.(sp) + bic (r3)+, at -(r0) + -10.(r0) + bic (r4)+,r0 + bic (sp),r2 + bic (r5)+,r0 + 2 + bic (r5)+,outbf+2(r2) + bic (r5)+,-(r0) + 2 + bic (r5)+,@(r0)+ + bic (r5)+,-(r2) + +/ sys call wrappers +sdiv: + mov 4(r4),r0 + clr r1 + sys 0; 6 / div + adc r1 + mov r1,r0 + rts pc + +sopen: + bic (r5),-(sp) + bic (r5), at -(r0) + mov 4(r4),0f + mov 6(r4),0f+2 + sys open; 0:.=.+2; 0:.=.+2 + bec 1f + mov $-1,r0 +1: + rts pc + +sclose: + bic (sp),r4 + bic (sp),sp + mov 4(r4),0f + mov 0f+2,r0 + tstb 0f+1 + beq 1f + sys write; 0:.=.+2; 2 + br 2f +1: + sys write; 0:.=.+2; 1 +2: + mov 0f,r0 + rts pc + +funct1: + bic (sp), at -(r4) + bic (sp), at -(sp) + rts pc + +funct2: + 0 + 1 + +sread: + bic (sp),-(sp) + bic (sp),-(r0) + mov 4(r4),r0 + mov 6(r4),0f + mov 8.(r4),0f+2 + sys read; 0:.=.+2; 0:.=.+2 + bec 1f + mov $-1,r0 +1: + rts pc + +/ interpreter dispatch +disp: + mov @(sp)+,@(sp)+ + jmp @(r5)+ + +disp2: + mov (sp)+,r0 + mov r0,@(sp)+ + mov r0,-(sp) + jmp @(r5)+ + +disp3: + movb (sp)+,@(sp)+ + jmp @(r5)+ + +disp4: + mov (sp)+,r0 + movb r0,@(sp)+ + mov r0,-(sp) + jmp @(r5)+ + +disp5: + bis (sp)+,(sp) + jmp @(r5)+ + +disp6: + com (sp) + bic (sp)+,(sp) + jmp @(r5)+ + +/ comparison primitives +cmpne: + cmp (sp)+,(sp)+ + beq 1f + clr -(sp) + jmp @(r5)+ + +cmpeq: + cmp (sp)+,(sp)+ + bne 1f + clr -(sp) + jmp @(r5)+ + +cmpge: + cmp (sp)+,(sp)+ + bge 1f + clr -(sp) + jmp @(r5)+ + +cmpgt: + cmp (sp)+,(sp)+ + bgt 1f + clr -(sp) + jmp @(r5)+ + +cmple: + cmp (sp)+,(sp)+ + ble 1f + clr -(sp) + jmp @(r5)+ + +cmplt: + cmp (sp)+,(sp)+ + blt 1f + clr -(sp) + jmp @(r5)+ + +1: + mov $1,-(sp) + jmp @(r5)+ + +/ memory operations +memop1: + mov 2(sp),-(r3) + sub (sp)+,hession+4 + mov (r3)+,(sp) + jmp @(r5)+ + +memop2: + mov 2(sp),(r3) + mov (sp)+,hession+4 + mov (r3),(sp) + jmp @(r5)+ + +/ arithmetic +add: + add (sp)+,(sp) + jmp @(r5)+ + +sub: + sub (sp)+,(sp) + jmp @(r5)+ + +mul: + mov 2(sp),(r3) + mov (sp)+,hession + mov hession+2,(sp) + jmp @(r5)+ + +swap: + mov (sp)+,(r3)+ + mov (sp)+,(r3) + mov -(r3),-(sp) + jmp @(r5)+ + +div: + mov 2(sp),(r3) + mov (sp)+,hession + mov (r3),(sp) + jmp @(r5)+ + +neg: + neg (sp) + jmp @(r5)+ + +/ indirection +indir: + mov @(sp)+,-(sp) + jmp @(r5)+ + +indirb: + movb @(sp)+,r0 + mov r0,-(sp) + jmp @(r5)+ + +/ logical not +not: + tst (sp)+ + bne 1f + mov $1,-(sp) + jmp @(r5)+ +1: + clr -(sp) + jmp @(r5)+ + +/ increment/decrement +preinc: + inc @0(sp) + mov @(sp)+,-(sp) + jmp @(r5)+ + +postinc: + inc @(sp)+ + jmp @(r5)+ + +preinc2: + add $2, at 0(sp) + mov @(sp)+,-(sp) + jmp @(r5)+ + +postinc2: + add $2,@(sp)+ + jmp @(r5)+ + +predec: + dec @0(sp) + mov @(sp)+,-(sp) + jmp @(r5)+ + +postdec: + dec @(sp)+ + jmp @(r5)+ + +predec2: + sub $2, at 0(sp) + mov @(sp)+,-(sp) + jmp @(r5)+ + +postdec2: + sub $2,@(sp)+ + jmp @(r5)+ + +/ post operations +postop1: + mov (sp)+,r0 + mov (r0),-(sp) + inc (r0) + jmp @(r5)+ + +postop2: + mov (sp)+,r0 + mov (r0),-(sp) + add $2,(r0) + jmp @(r5)+ + +postop3: + mov (sp)+,r0 + mov (r0),-(sp) + dec (r0) + jmp @(r5)+ + +postop4: + mov (sp)+,r0 + mov (r0),-(sp) + sub $2,(r0) + jmp @(r5)+ + +/ frame operations +frame1: + mov (r5)+,r0 + add r4,r0 + mov (r0),-(sp) + jmp @(r5)+ + +frame2: + mov (r5)+,-(sp) + add r4,(sp) + jmp @(r5)+ + +frame3: + mov (r5)+,r0 + add r4,r0 + movb (r0),r0 + mov r0,-(sp) + jmp @(r5)+ + +/ constants +const1: + mov @(r5)+,-(sp) + jmp @(r5)+ + +const2: + mov (r5)+,-(sp) + jmp @(r5)+ + +const3: + movb @(r5)+,r0 + mov r0,-(sp) + jmp @(r5)+ + +/ array operations +arr1: + asl (sp) + add (sp)+,(sp) + mov @(sp)+,-(sp) + jmp @(r5)+ + +arr2: + add (sp)+,(sp) + movb @(sp)+,r0 + mov r0,-(sp) + jmp @(r5)+ + +arr3: + asl (sp) + add (sp)+,(sp) + jmp @(r5)+ + +shiftl: + asl (sp) + jmp @(r5)+ + +/ function call +fcall: + mov (sp)+,r0 + mov r5,-(sp) + mov r4,-(sp) + mov sp,r4 + mov r0,r5 + jsr pc,@(r5)+ + mov r4,sp + mov (sp)+,r4 + mov (sp)+,r5 + add (r5)+,sp + mov r0,-(sp) + jmp @(r5)+ + +fcall2: + mov (sp)+,r0 + mov r5,-(sp) + mov r4,-(sp) + mov sp,r4 + mov r0,r5 + jsr pc,@(r5)+ + mov r4,sp + mov (sp)+,r4 + mov (sp)+,r5 + add (r5)+,sp + jmp @(r5)+ + +/ control flow +jind: + mov (sp),r0 + jmp @-2(r4) + +ret: + mov (sp)+,r5 + jmp @(r5)+ + +setsp: + mov r4,r0 + sub (r5)+,r0 + mov r0,sp + jmp @(r5)+ + +setsp2: + mov r4,r0 + sub (r5)+,r0 + mov r0,sp + mov r0,-(sp) + jmp @(r5)+ + +jmp1: + mov (r5)+,r5 + jmp @(r5)+ + +beq1: + mov (r5)+,r0 + tst (sp)+ + bne 1f + mov r0,r5 +1: + jmp @(r5)+ + +switch: + mov (r5)+,r5 + mov (sp)+,r0 + cmp r0,(r5)+ + beq 2f + tst (r5)+ + bne switch+4 + jmp @(r5)+ +2: + mov (r5)+,r0 + beq 1f + mov r0,r5 +1: + jmp @(r5)+ + +/ data +.bss +regs: .=.+12. +hession: .=.+12. +outbf: .=.+520. +mq = 177304 diff --git a/cmd/sort.s b/cmd/sort.s new file mode 100644 index 0000000..39473b6 --- /dev/null +++ b/cmd/sort.s @@ -0,0 +1,265 @@ +/ sort -- sort lines + + cmp (sp)+,$3 + beq 1f + sys exit +1: + tst (sp)+ + mov (sp)+,0f + sys open; 0:..; 0 + bec 1f + sys exit +1: + mov r0,fin + mov (sp)+,r0 + jsr r5,fcreat; obuf + bec 1f + sys exit +1: + jsr pc,sort + jsr pc,output + sys exit + +output: + mov r1,-(sp) + cmp r1,r2 + bhi 1f + mov (r1)+,r5 + jsr pc,getc1 + mov r0,-(sp) + jsr r5,putc; obuf + mov (sp)+,r0 + cmp r0,$'\n + beq output + cmp r0,$4 + beq output + br 2b +1: + jsr r5,flush; obuf + mov (sp)+,r1 + rts pc + +getc1: + mov r5,r0 + bic $777,r0 + cmp r0,blkno + beq 1f + mov r0,blkno + mov fin,r0 + sys seek; -1; 0 + mov fin,r0 + sys read; inbuf; 512. + mov r0,nleft +1: + mov r5,r0 + bic $177000,r0 + inc r5 + cmp r0,nleft + blt 1f + mov $4,r0 + rts pc +1: + movb inbuf(r0),r0 + rts pc + +compare: + mov r5,-(sp) + mov r4,-(sp) + mov r0,-(sp) + mov $line,r4 + cmpb (r4),$'( + bne 1f + inc r4 +1: + cmpb 3720.(r5),$'( + beq 2f + cmpb 3720.(r5),(r4)+ + blt less + bgt more +2: + cmpb 3721.(r5),(r4)+ + blt less + bgt more + mov (r5),r5 + add $2,r5 + jsr pc,getc1 + cmpb r0,$'A + blo 3f + cmpb r0,$'Z + bhi 3f + add $40,r0 +3: + cmpb r0,(r4)+ + beq 1b + blt less +more: + mov (sp)+,r0 + mov (sp)+,r4 + mov (sp)+,r5 + tst $-1 + rts pc + +less: + mov (sp)+,r0 + mov (sp)+,r4 + mov (sp)+,r5 + tst $1 + rts pc + +sort: + mov $lines,r1 + mov r1,r2 + jsr r5,getline + rts pc + +insert: + mov lineptr,(r1) + mov lineptr+2,3720.(r1) + jsr r5,getline + rts pc + +bsearch: + mov r1,r3 + mov r2,r4 +1: + mov r3,r5 + add r4,r5 + ror r5 + bic $1,r5 + jsr pc,compare + beq found + blt 2f + cmp r5,r4 + bcc found + tst (r5)+ + mov r5,r3 + br 1b +2: + cmp r3,r4 + bcc found + mov r5,r4 + br 1b +found: + tst (r5)+ + tst (r2)+ + cmp r2,r5 + beq 2f + mov r2,r3 +1: + mov -(r3),2(r3) + mov 3720.(r3),3722.(r3) + cmp r3,r5 + bhi 1b +2: + mov lineptr,(r5) + mov lineptr+2,3720.(r5) + br bsearch-4 + +getline: + mov r5,-(sp) + cmp r2,$lines+2000. + bcc 1f + mov loc,r5 + mov $line,r3 + mov r5,lineptr + jsr pc,getc1 + cmp r0,$4 + bne 2f +1: + mov (sp)+,r5 + rts r5 +2: + cmp r0,$'\n + beq 3f + cmp r3,$line+199. + bcc 1b + cmpb r0,$'A + blo 4f + cmpb r0,$'Z + bhi 4f + add $40,r0 +4: + movb r0,(r3)+ + br 1b +3: + clrb (r3)+ + mov r5,loc + mov (sp)+,r5 + tst (r5)+ + rts r5 + +fcreat: + mov r1,-(sp) + mov (r5)+,r1 + mov r0,0f + sys creat; 0:..; 17 + bec 1f + mov r0,(r1)+ + clr (r1)+ + clr (r1)+ + mov (sp)+,r1 + rts r5 +1: + mov $-1,(r1)+ + br 3b + +getword: + mov (r5),0f + mov (r5)+,0f+2 + mov r0,-(sp) + jsr r5,getc; 0:.. + mov (sp)+,r0 + swab r0 + jsr r5,getc; 0:.. + rts r5 + +putc: + mov r1,-(sp) + mov (r5)+,r1 + dec 2(r1) + bge 1f + mov r0,-(sp) + jsr pc,flush1 + mov (sp)+,r0 +1: + movb r0, at 4(r1) + inc 4(r1) + mov (sp)+,r1 + rts r5 + +flush: + mov r0,-(sp) + mov r1,-(sp) + mov (r5)+,r1 + jsr pc,flush1 + mov (sp)+,r1 + mov (sp)+,r0 + rts r5 + +flush1: + mov r1,r0 + add $6,r0 + mov r0,-(sp) + mov r0,0f + neg r0 + add 4(r1),r0 + ble 1f + mov r0,0f+2 + mov (r1),r0 + sys write; 0:..; 0:.. +1: + mov (sp)+,4(r1) + mov $127.,2(r1) + rts pc + +fin: .=.+2 +blkno: -1 +nleft: .=.+2 +loc: inbuf +lineptr: .=.+4 +line: .=.+200. + .even +lines: .=.+2000. + .=.+3722. +inbuf: .=.+512. +obuf: .=.+134. diff --git a/cmd/stat.s b/cmd/stat.s new file mode 100644 index 0000000..ae10229 --- /dev/null +++ b/cmd/stat.s @@ -0,0 +1,298 @@ +/ stat -- print file status + + mov sp,r5 + sys open; 1:..; 0 + bec 1f + sys read; stbuf; 512. + add r0,uids +1: + mov (r5)+,r0 + mov r0,argc + mov r0,argv + cmp r0,$2 + beq 1f + jsr r3,mesg; +1: + tst (r5)+ + cmp argc,$2 + bge 1f + sys exit +1: + dec argc + mov (r5)+,0f + sys stat; 0:..; stbuf + bec 1f + mov 0b,0f + jsr r3,mesg; 0:.. + jsr r3,mesg; + br 1b +1: + mov $stbuf,r4 + mov (r4)+,r2 + jsr r3,prdec; 3 + jsr r3,mesg; < inode mode nl uid size t.mod.\n\0> + bit $10000,(r4) + beq 2f + jsr r3,putc; + br 3f +2: + jsr r3,putc; +3: + bit $40000,(r4) + beq 4f + jsr r3,putc; + br 5f +4: + jsr r3,putc; <-\0> +5: + bit $40,(r4) + beq 6f + jsr r3,putc; + br 7f +6: + bit $20,(r4) + beq 8f + jsr r3,putc; + br 7f +8: + jsr r3,putc; <-\0> +7: + bit $10,(r4) + beq 9f + jsr r3,putc; + br 10f +9: + jsr r3,putc; <-\0> +10: + bit $4,(r4) + beq 11f + jsr r3,putc; + br 12f +11: + jsr r3,putc; <-\0> +12: + bit $2,(r4) + beq 13f + jsr r3,putc; + br 14f +13: + jsr r3,putc; <-\0> +14: + bit $1,(r4)+ + beq 15f + jsr r3,putc; + br 16f +15: + jsr r3,putc; <-\0> +16: + jsr r3,mesg; < \0> + movb (r4)+,r2 + jsr r3,prdec; 2 + movb (r4)+,r2 + jsr pc,pruid + mov (r4)+,r2 + jsr r3,prdec; 5 + jsr r3,mesg; < \0> + add $20.,r4 + mov (r4)+,r2 + mov (r4)+,mq + mov r2,ac + mov $1,r0 + jsr pc,prdate + jsr r3,mesg; < \0> + mov -2(r5),0f + jsr r3,mesg; 0:.. + jsr r3,mesg; <\n\0> + jmp 1b + +pruid: + mov $stbuf+22.,r1 + cmp r1,uids + bcc 1f + mov r1,0f +2: + tstb (r1)+ + beq 3f + cmpb -1(r1),$': + bne 2b + clrb -1(r1) +3: + clr mq + movb (r1)+,r0 + sub $'0,r0 + cmp r0,$9. + bhi 4f + mov $10.,mul + add r0,mq + br 3b +4: + cmp mq,r2 + bne 1f + jsr r3,mesg; < \0> + jsr r3,mesg; 0:.. + mov 0b,r1 + mov $6,-(sp) +5: + tstb (r1)+ + beq 6f + dec (sp) + br 5b +6: + jsr r3,mesg; < \0> + dec (sp) + bgt 6b + tst (sp)+ + emt 7 + jsr r3,mesg; < \0> + jsr r3,prdec; 3 + jsr r3,mesg; <\n\0> + emt 7 + +putc: + mov (r3)+,0f + mov $1,r0 + sys write; 0:..; 1 + emt 3 + +mesg: + mov r2,-(sp) + mov (r3),r1 + clr r2 +1: + tstb (r1)+ + beq 2f + inc r2 + br 1b +2: + mov (r3)+,0f + mov r2,0f+2 + mov $1,r0 + sys write; 0:..; 0:.. + mov (sp)+,r2 + emt 3 + +prdec: + mov $6,r1 + mov $stbuf+22.,r0 +1: + mov r2,mq + clr ac + mov $10.,div + add $'0,ac + movb ac,-(r0) + clr ac + dec r1 + bne 1b + cmp r0,$stbuf+21. + beq 2f + cmpb (r0),$'0 + bne 2f + movb $' ,(r0)+ + br 2b-4 +2: + mov $stbuf+22.,0f + sub (r3),0f + mov (r3)+,0f+2 + mov $1,r0 + sys write; 0:..; 0:.. + emt 3 + +1: + .even +uids: stbuf+22. + +prdate: + mov r1,-(sp) + sub $16.,sp + mov r0,r1 + mov sp,r0 + jsr pc,fmtdate + mov r0,0f + mov r1,r0 + sys write; 0:..; 17. + add $16.,sp + mov (sp)+,r1 + rts pc + +fmtdate: + mov r2,-(sp) + mov r3,-(sp) + cmp ac,yrdays + blo 1f + bhi 2f + cmp mq,yrdays+2 + blo 1f +2: + mov ac,-(sp) + sub yrdays+2,mq + sbc (sp) + sub yrdays,(sp) + mov (sp)+,ac + mov $29.,daylen +1: + mov $-4,lsh + mov $26300.,div + mov mq,r3 + mov ac,mq + mov $2,lsh + mov $17.,div + add $17.,r0 + jsr r5,digit; 10. + jsr r5,digit; 6 + movb $':,-(r0) + jsr r5,digit; 10. + jsr r5,digit; 6 + movb $':,-(r0) + mov r3,mq + mov $24.,div + mov mq,r3 + mov ac,mq + jsr r5,digit; 10. + jsr r5,digit; 10. + mov $montab,r2 +1: + cmp (r2),r3 + bgt 2f + sub (r2)+,r3 + br 1b +2: + movb $' ,-(r0) + sub $montab,r2 + asl r2 + add $months,r2 + inc r3 + mov r3,mq + jsr r5,digit; 10. + tst mq + beq 1f + add $'0,mq + movb mq,-(r0) + br 2f +1: + movb $' ,-(r0) +2: + movb $' ,-(r0) + movb -(r2),-(r0) + movb -(r2),-(r0) + movb -(r2),-(r0) + mov (sp)+,r3 + mov (sp)+,r2 + rts pc + +digit: + clr ac + mov (r5)+,div + add $'0,ac + movb ac,-(r0) + rts r5 + +yrdays: 57544.; 4480. +daylen: 31.; 28.; 31.; 30.; 31.; 30.; 31.; 31.; 30.; 31.; 30. +montab = .-2 +months: + < \0Jan\0Feb\0Mar\0Apr\0May\0Jun\0Jul\0Aug\0Sep\0Oct\0Nov\0Dec\0> + .even + +argc: .=.+2 +argv: .=.+2 +stbuf: .=.+40. diff --git a/cmd/tap.s b/cmd/tap.s new file mode 100644 index 0000000..6d4727f --- /dev/null +++ b/cmd/tap.s @@ -0,0 +1,666 @@ +/ tap -- tape archiver + + br start + 07136 + 0 + 0 + + ble 1f + 0 + +start: + sys stat; 0; 0 + mov (sp),argc + mov (sp)+,argc2 + mov $tapdev,path + incb tapname+8. + tst (sp)+ + cmp argc2,$2 + bge 1f + mov $2,argc2 + br main +1: + mov (sp)+,r0 + mov sp,argp + movb (r0)+,r1 + beq main + mov $optbl,r2 +1: + cmp r1,(r2)+ + beq 2f + tst (r2)+ + bne 1b + br baduse +2: + jsr pc,@(r2)+ + br 1b + +main: + sys intr; 0 + jsr pc,topen + incb moession + sys chmod; tapdev; 0 + mov $dir,r4 + jmp @path + +topen: + sys open; tapdev; 0 + bes opnerr + mov r0,tfi + sys open; tapdev; 1 + bes opnerr + mov r0,tfo + sys stat; tapdev; stbuf + bit $1,stbuf+2 + beq opnerr + rts pc + +opnerr: + jsr r5,mesg + + .even + jmp done + +setpath: + cmp path,$tapdev + bne baduse + mov (r5)+,path + rts r5 + +chknull: + mov (r5)+,r0 + beq 1f + tstb (r0) + beq chknull + br baduse +1: + rts r5 + +baduse: + jsr r5,mesg + + .even + jmp done + +optbl: + '0; setdv + '1; setdv + '2; setdv + '3; setdv + '4; setdv + '5; setdv + '6; setdv + '7; setdv + 'c; docr + 'd; dodel + 'f; dofil + 'l; dolist + 'm; domkd + 'r; dorepl + 't; dotbl + 'u; doupd + 'v; dover + 'w; dowrt + 'x; doextr + 0; 0 + +setdv: + movb r1,tapname+8. + rts pc + +dodel: + incb dession + rts pc + +dofil: + incb fession + rts pc + +docr: + jsr r5,setpath; tapdev + rts pc + +domkd: + incb moession + rts pc + +doupd: + incb uession + jsr r5,setpath; tapdev + rts pc + +dorepl: + clrb uession + jsr r5,setpath; tapdev + rts pc + +dotbl: + incb tession + jsr r5,setpath; tapstr + rts pc + +dover: + incb vession + rts pc + +dowrt: + incb wession + rts pc + +doextr: + jsr r5,setpath; fpath + rts pc + +/ table of contents +dottab: + .=.+512. + +/ directory reading +dotab: + jsr r5,chknull; mnp; nnp; pnp; 0 + cmp argc2,$2 + bgt 1f + jmp baduse +1: + jsr pc,readdir + jsr r5,match; dir2 + jsr pc,readtape + br endtab + +doread: + jsr r5,chknull; pnp; 0 + tstb dession + beq 1f + jsr pc,cleardir + br 2f +1: + jsr pc,readdir +2: + jsr pc,readtape + jsr pc,prstat + jsr pc,prdir + br endtab + +domake: + jsr r5,chknull; mnp; nnp; 0 + jsr r5,namecpy; dir2; nname + jsr pc,readdir + jsr r5,match; dir2 + br endmak + +doupdt: + jsr r5,chknull; mnp; nnp; pnp; snp; rnp; 0 + jsr r5,namecpy; dir2; nname + jsr pc,readdir + jsr r5,match; dir2 + jsr pc,doproc + tstb tession + beq prhdr + jsr r5,mesg + + .even +prhdr: + jsr r5,match; dir2 + br endprc + +endtab: + mov $dir,r4 + jsr pc,readdir + jsr pc,prtape +endmak: + jsr pc,doproc + jsr r5,mesg; ; .even + +done: + sys exit + +doproc: + tstb moession + beq 1f + sys chmod; tapdev; 017 + mov tfi,r0 + sys close + mov tfo,r0 + sys close + clrb moession + sys intr; 1 +1: + rts pc + +namecpy: + mov (r5)+,r0 + mov $dir2,r1 +1: + mov (r0)+,(r1)+ + cmp r0,(r5) + bcs 1b + cmp r1,$dir2+512. + blos 1f + jsr r5,mesg; ; .even + iot +1: + tst (r5)+ + rts r5 + +npath: + mov r3,-(sp) + mov r2,-(sp) + mov r1,-(sp) + mov (r5),r2 + mov r2,r1 + bicb $177600,(r2) + cmpb (r2),$'/ + bne 1f + jsr pc,findent + inc r2 + br .-10 +1: + tstb (r2)+ + bne .-4 + mov r4, at 0(sp) + mov (r5)+,r2 + mov r2,r1 + cmpb (r2),$'/ + bne 2f + jsr pc,findent + movb r0,(r4)+ + inc r2 + br .-14 +2: + tstb (r2)+ + bne .-4 + movb (r1)+,(r4)+ + bne .-4 + mov (sp)+,r1 + mov (sp)+,r2 + mov (sp)+,r3 + rts r5 + +findent: + mov $dir,r3 + mov $200,-(sp) + cmp r3,r4 + bcc newent + cmpb (r3)+,$200 + bne .-6 + inc (sp) + mov r1,r0 + cmpb (r3),$200 + beq .-12 + cmp r0,r2 + bcc 1f + cmpb (r0)+,(r3)+ + beq .-10 + br .-22 +1: + tstb (r3) + bne .-24 + br 2f + +newent: + movb $200,(r4)+ + inc (sp) + mov r1,r0 + cmp r0,r2 + bcc 1f + movb (r0)+,(r4)+ + br .-6 +1: + clrb (r4)+ +2: + mov (sp)+,r0 + rts pc + +epath: + mov r3,-(sp) + mov r2,-(sp) + mov r1,-(sp) + mov (r1),r1 + mov (r5)+,r2 + movb (r1)+,r0 + beq 3f + blt 1f + movb r0,(r2)+ + br .-10 +1: + mov $dir,r3 + bic $177600,r0 + cmpb (r3)+,$200 + bne .-4 + dec r0 + bne .-4 + movb (r3)+,(r2)+ + bne .-4 + movb $'/,-1(r2) + br epath+16. +3: + clrb (r2)+ + mov (sp)+,r1 + mov (sp)+,r2 + mov (sp)+,r3 + rts r5 + +tapdev: + .even + +/ message subroutine +prints: + movb (r1)+,r0 + beq 1f + jsr pc,putc + br prints +1: + rts pc + +mesg: + movb (r5)+,r0 + beq 1f + jsr pc,putc + br mesg +1: + inc r5 + bic $1,r5 + rts r5 + +putc: + movb r0,ch + mov $1,r0 + sys write; ch; 1 + rts pc + +getc: + clr r0 + sys read; ch; 1 + movb ch,r0 + rts pc + +cleardir: + mov $dir2,r1 + mov $192.,r2 + jsr pc,1f + dec r2 + bne .-4 + rts pc +1: + clr (r1)+ + clr (r1)+ + clr (r1)+ + clr (r1)+ + clr (r1)+ + clr (r1)+ + clr (r1)+ + clr (r1)+ + rts pc + +readdir: + mov tfi,r0 + sys read; dir; 512. + mov $dir,r4 + add r0,r4 + rts pc + +readtape: + mov tfi,r0 + sys read; tbuf; 512. + jsr pc,chksum + bne csumerr + rts pc + +chksum: + mov $tbuf,r0 + clr r1 +1: + add (r0)+,r1 + cmp r0,$tbuf+512. + bne 1b + tst r1 + rts pc + +csumerr: + jsr r5,mesg + + .even + jmp done + +rderr: + jsr r5,mesg + + .even + jmp done + +wrterr: + jsr r5,mesg + + .even + jmp done + +seekerr: + jsr r5,mesg + + .even + jmp done + +match: + mov r3,-(sp) + mov r2,-(sp) + mov r1,-(sp) + mov (r5)+,r1 + mov $dir,r2 +1: + cmp r2,r4 + bcc 2f + tstb (r2)+ + beq 1b + jsr pc,cmpmatch + beq 3f + br 1b +2: + mov $-1,r0 + br 4f +3: + mov r2,r0 + sub $dir,r0 +4: + mov (sp)+,r1 + mov (sp)+,r2 + mov (sp)+,r3 + rts r5 + +cmpmatch: + mov r1,-(sp) +1: + cmpb (r1)+,(r2)+ + bne 2f + tstb -1(r1) + bne 1b + clr r0 + br 3f +2: + mov $1,r0 +3: + mov (sp)+,r1 + rts pc + +prtape: + jsr r5,mesg + < entries\0> + .even + rts pc + +prstat: + jsr r5,mesg + < used\0> + .even + rts pc + +prdir: + jsr r5,mesg + < free\0> + .even + rts pc + +prfree: + jsr r5,mesg + < last\0> + .even + rts pc + +prdec: + clr ac + mov (r5)+,div + add $'0,ac + movb ac,-(r1) + rts r5 + +prmon: + jsr r5,prdec; 10. + cmp r0,$2 + beq 1f + mov (r5)+,r0 + jsr pc, at putca + rts r5 +1: + mov $'-,r0 + jsr pc, at putca + tst (r5)+ + rts r5 + +prdiv: + clr ac + mov (r5)+,div + add $'0,ac + movb ac,-(r1) + rts r5 + +/ archive file routines +dofile: + mov 4(r1),r3 + beq 2f + mov 12.(r1),r0 + jsr pc,setwrt + sys creat; wrbuf; 0 + bes 1f + mov r0,r2 + cmp r3,$512. + bcs 3f + jsr pc,rdbuf + mov r2,r0 + sys write; dbuf; 512. + bes 1f + cmp r0,$512. + bne 1f + sub $512.,r3 + br .-30 +3: + mov r3,0f + beq 4f + jsr pc,rdbuf + mov r2,r0 + sys write; dbuf; 0:.. + bes 1f + cmp r0,.-6 + bne 1f +4: + mov r2,r0 + sys close + movb 3(r1),0f + sys chown; wrbuf; 0:.. + movb 2(r1),0f + sys chmod; wrbuf; 0:.. + mov 10.(r1),mq + mov 6(r1),ac + sys smdate; wrbuf +2: + rts pc +1: + tstb @$pnp + beq 2f + jsr r5,mkmiss + br dofile+6 +2: + clr mq + sys smdate; wrbuf + mov r2,r0 + sys close +opnerr2: + mov $wrbuf,r1 + jsr pc,prints + jsr r5,mesg + < -- create error\n\0> + .even + rts pc + +mkmiss: + jsr r5,mesg + < not found\0> + .even + rts pc + +phaserr: + jsr r5,mesg + < -- Phase error\0> + .even + rts pc + +ovflerr: + jsr r5,mesg + + .even + jmp done + +rdbuf: + mov tfi,r0 + sys read; dbuf; 512. + rts pc + +wrbuf: + .=.+32. + .even +setwrt: + mov r0,0f + sys open; 0:..; 0 + rts pc + +putca: + putc + +/ EAE registers +div = 177300 +ac = 177302 +mq = 177304 + +month: + .even + +tapstr: + .even +fpath: .=.+32. + .even + +.bss +ch: .=.+2 +argc: .=.+2 +argc2: .=.+2 +argp: .=.+2 +path: .=.+2 +tfi: .=.+2 +tfo: .=.+2 +dession: .=.+2 +fession: .=.+2 +moession: .=.+2 +tession: .=.+2 +uession: .=.+2 +vession: .=.+2 +wession: .=.+2 +tapname: .=.+16. +stbuf: .=.+36. +dir: .=.+1024. +dir2: .=.+1024. +tbuf: .=.+512. +dbuf: .=.+512. +nname: .=.+64. +mnp: .=.+2 +nnp: .=.+2 +pnp: .=.+2 +snp: .=.+2 +rnp: .=.+2 diff --git a/cmd/tm.s b/cmd/tm.s new file mode 100644 index 0000000..b2dbec3 --- /dev/null +++ b/cmd/tm.s @@ -0,0 +1,284 @@ +/ tm -- system timing utility + + br start + beq 1f + 0 + 0 + + bge 1f + 0 + +start: + sys open; timfil; 0 + bes notime + mov r0,r1 + sys read; tbuf; 26. + mov r1,r0 + sys close + br 1f + +notime: + sys time + mov ac,ovrd + mov mq,ovrd+2 +1: + sys creat; timfil; 017 + bec 1f + jsr r5,mesg + + .even +1: + sys exit + +timeerr: + mov r0,r2 + sys open; sbfil; 0 + bec 1f + jsr r5,mesg + + .even +1: + sys exit + +openerr: + mov r0,r1 + sys read; sbuf; 1024. + mov r1,r0 + sys close + mov ovrd,dsk+2 + mov ovrd+2,dsk+4 + mov r2,r0 + sys write; sbuf+6; 26. + mov r2,r0 + sys close + cmp (sp),$1 + blos prstats + jsr pc,argproc + clr (sp) + br start + +prstats: + mov $tbuf,r1 + mov $sbuf+6,r2 + jsr r5,mesg; ; .even + jsr pc,prline + jsr r5,mesg; ; .even + jsr pc,prline + jsr r5,mesg; ; .even + jsr pc,prline + jsr r5,mesg; ; .even + jsr pc,prline + jsr r5,mesg; ; .even + jsr pc,prline + tst (sp) + beq done + jsr r5,mesg; ; .even + movb (r2),r0 + bic $177400,r0 + jsr pc,prdec + jsr r5,mesg; <,\0>; .even + movb 1(r2),r0 + bic $177400,r0 + jsr pc,prdec + jsr r5,mesg; < \0>; .even +1: + sub (r1),(r2) + movb (r2)+,r0 + bic $177400,r0 + jsr pc,prdec + jsr r5,mesg; <,\0>; .even + movb (r2)+,r0 + bic $177400,r0 + jsr pc,prdec + jsr r5,mesg; <\n\0>; .even + +done: + sys exit + +dofork: + sys fork + br 1f + bec 1f +1: + sys wait + rts pc + +argproc: + tst (sp)+ + mov (sp)+,r0 + tst (sp)+ + mov $tbuf,r1 + mov $argv,r2 + sys stat; argv; argp + mov (sp)+,r3 + mov r2,(r1)+ +1: + movb (r3)+,(r2)+ + bne 1b + dec r0 + cmp r0,$1 + bgt 1b + clr (r1)+ + sys utime + sys fstat + sys exec; argv; tbuf + mov $binsh,dexec + mov $,dexec+2 + mov $,dexec+4 + sys exec; binsh; tbuf + jsr r5,mesg; ; .even + +done2: + sys exit + +prtnum: + mov $nbuf+3,r4 + mov r0,mq + jsr r5,digit; 10. + jsr r5,digit; 10. + jsr r5,digit; 10. + jsr r5,digit; 10. + cmpb (r4),$'0 + bne 1f + movb $' ,(r4)+ + cmp r4,$nbuf+5 + bne .-10 +1: + mov $1,r0 + sys write; nbuf+2; 4 + rts pc + +prline: + tst 2(sp) + beq 2f + jsr r5,mesg; < \0>; .even + mov 2(r2),mq + cmp r2,$sbuf+6 + bne 1f + mov (r2),-(sp) + sub ovrd+2,mq + sbc (sp) + sub ovrd,(sp) + mov (sp)+,ac + br 3f +1: + mov (r2),ac +3: + jsr pc,prdiv +2: + sub 2(r1),2(r2) + sbc (r2) + sub (r1),(r2) + mov 2(r2),mq + mov (r2),ac + jsr pc,prdiv + mov dsk,mq + mov $6,div + add $'0,mq + movb mq,11(r4) + jsr r5,digit; 10. + br 4f + movb $':',(r4) +4: + jsr r5,digit; 10. + br 5f + movb $':',(r4) +5: + jsr r5,digit; 10. + jsr r5,digit; 10. + jsr r5,digit; 10. + cmpb (r4),$'0 + beq 1f + cmpb (r4),$': + bne 2f +1: + movb $' ,(r4)+ + cmp r4,$nbuf+2 + bne .-16 +2: + mov $1,r0 + sys write; nbuf+2; 9 + rts pc + +prdiv: + mov $7020,div + mov mq,r3 + mov ac,mq + clr ac + mov $'<,div + mov ac,dsk + mov $nbuf+3,r4 + jsr r5,digit; 10. + jsr r5,digit; 6 + movb $':',(r4) + mov r3,mq + jsr r5,digit; 10. + jsr r5,digit; 10. + jsr r5,digit; 10. + cmpb (r4),$'0 + beq 1f + cmpb (r4),$': + bne 2f +1: + movb $' ,(r4)+ + cmp r4,$nbuf+2 + bne .-16 +2: + mov $1,r0 + sys write; nbuf+2; 9 + rts pc + +digit: + clr ac + mov (r5)+,div + add $'0,ac + movb ac,-(r4) + rts r5 + +mesg: + movb (r5)+,ch + beq 1f + mov $1,r0 + sys write; ch; 1 + br mesg +1: + inc r5 + bic $1,r5 + rts r5 + +prdec: + clr ac + mov $10.,div + mov ac,-(sp) + tst mq + beq 1f + jsr pc,prdec +1: + add $'0,(sp) + mov (sp)+,ch + mov $1,r0 + sys write; ch; 1 + rts pc + +timfil: +tmpfil: +devrf0: + .even + +.bss +ch: .=.+2 +ovrd: .=.+4 +dsk: .=.+4 +tbuf: .=.+32. +sbuf: .=.+1024. +nbuf: .=.+16. +argv: .=.+64. +argp: .=.+32. +binsh: .=.+16. +dexec: .=.+8. +sbfil: .=.+16. + +/ EAE registers +div = 177300 +ac = 177302 +mq = 177304 diff --git a/cmd/un.s b/cmd/un.s new file mode 100644 index 0000000..53f565a --- /dev/null +++ b/cmd/un.s @@ -0,0 +1,79 @@ +/ un -- print undefined symbols from a.out + + cmp (sp)+,$2 + blt 1f + tst (sp)+ + mov (sp)+,0f +1: + sys open; 0:..; 0 + bes error + mov r0,r1 + sys read; hdr; 16. + cmp r0,$16. + bne error + cmp hdr,$407 + bne error + mov hdr+2,r2 + add hdr+4,r2 + cmp hdr+14.,$1 + beq 1f + asl r2 +1: + add $16.,r2 + mov r2,0f + mov r1,r0 + sys seek; 0:..; 0 + add hdr+6.,0f + sys seek; 0f+2; 0 +loop: + mov r1,r0 + sys read; sym; 12. + mov $sym,r1 + mov r1,r2 + add r0,r2 + cmp r1,r2 + blo 1f + tst filter + beq 2f + sys exit +2: + mov $' ,filter + mov $sym,r1 + br loop +1: + cmp filter,8.(r1) + bne next + mov r1,r3 + mov $name,r4 + mov $8.,r5 + bit $40,8.(r1) + beq 3f + movb $'_,(r4)+ + movb $'\b,(r4)+ +3: + movb (r3)+,(r4)+ + beq 4f + dec r5 + bne 3b +4: + movb $'\n,(r4)+ + sub $name,r4 + mov r4,0f + mov $1,r0 + sys write; name; 0:.. +next: + add $12.,r1 + br loop + +error: + mov $1,r0 + sys write; errmsg; 2 + sys exit +errmsg: + +0: + .even +filter: .=.+2 +hdr: .=.+16. +sym: .=.+12. +name: .=.+16. diff --git a/cmd/wc.s b/cmd/wc.s new file mode 100644 index 0000000..7a115cd --- /dev/null +++ b/cmd/wc.s @@ -0,0 +1,180 @@ +/ wc -- word count + + mov (sp)+,nfiles + tst (sp)+ + dec nfiles + ble done + +loop: + br 1f +2: + mov buf,r0 + sys close + dec nfiles + beq done +1: + clr words + clr lines + clr text + clr ctrl + mov $1,inflag + mov (sp),r0 + jsr r5,fopen; buf + bes error + jsr r5,getc; buf + bes pline + cmpb $'\n,r0 + bne 1f + inc lines + inc inflag + br 2f + +1: + cmpb $' ,r0 + beq 3f + cmpb $'\t,r0 + bne 4f +3: + clr inflag +2: + tst ctrl + bne gchar + inc ctrl + inc words + br gchar + +4: + cmpb $'.,r0 + bne 5f + tst inflag + beq gchar + inc text + jsr r5,getc; buf + cmpb $'\n,r0 + bne 4b + br gchar + +5: + clr inflag + clr ctrl +gchar: + br 2b + +pline: + jsr r5,mesg; <\n file: \0>; .even + mov (sp)+,r0 + jsr r5,mesg; 0:..; .even + jsr r5,mesg; < \0>; .even + jsr r5,decml; text + jsr r5,mesg; < text lines\n\0>; .even + jsr r5,decml; words + jsr r5,mesg; < control lines\n\0>; .even + jsr r5,decml; lines + jsr r5,mesg; < lines\n\0>; .even + jmp loop + +done: + sys exit + +mesg: + mov (r5)+,r1 + mov r1,r2 + mov r1,0f +1: + tstb (r1)+ + bne 1b + sub r2,r1 + mov r1,0f+2 + mov $1,r0 + sys write; 0:..; 0:.. + rts r5 + +decml: + mov @(r5)+,mq + mov $1,r0 + jsr pc,1f + rts r5 +1: + clr ac + mov $10.,div + mov ac,-(sp) + tst mq + beq 2f + jsr pc,1b +2: + add $'0,(sp) + mov (sp)+,ch + sys write; ch; 1 + rts pc + +fopen: + mov r1,-(sp) + mov (r5)+,r1 + mov r0,0f + sys open; 0:..; 0 + bec 1f + mov $-1,(r1) + mov (sp)+,r1 + sec + rts r5 +1: + mov r0,(r1)+ + clr (r1)+ + mov (sp)+,r1 + rts r5 + +getc: + mov (r5),0f + mov (r5)+,0f+2 + jsr r5,1f; 0:.. + bec 2f + rts r5 +2: + mov r0,-(sp) + jsr r5,1f; 0:.. + swab r0 + bis (sp)+,r0 + rts r5 +1: + mov r1,-(sp) + mov (r5)+,r1 + dec 2(r1) + bge 3f + mov r1,r0 + add $6,r0 + mov r0,0f + mov r0,4(r1) + mov (r1),r0 + sys read; 0:..; 512. + bec 4f +4: + tst r0 + bne 5f + mov (sp)+,r1 + sec + rts r5 +5: + dec r0 + mov r0,2(r1) +3: + clr r0 + bisb @4(r1),r0 + inc 4(r1) + mov (sp)+,r1 + rts r5 + +error: + mov $1,r0 + sys write; quest; 2 + sys exit +quest: + +inflag: .=.+2 + +ch: .=.+2 +text: .=.+2 +words: .=.+2 +ctrl: .=.+2 +lines: .=.+2 +nfiles: .=.+2 +buf: .=.+518. diff --git a/cmd/who.s b/cmd/who.s new file mode 100644 index 0000000..0abe522 --- /dev/null +++ b/cmd/who.s @@ -0,0 +1,150 @@ +/ who -- who is logged in + + cmp (sp)+,$1 + ble 1f + mov 2(sp),0f +1: + sys open; 0:..; 0 + bes error + mov r0,r1 +2: + mov r1,r0 + sys read; utmp; 16. + tst r0 + beq done + tst utmp + bne 3f + cmp 0b,$deffile + beq 2b + mov $1,r0 + sys write; blank; 8. + br 4f +3: + mov $1,r0 + sys write; utmp; 8. +4: + movb utmp+8.,ttyno + cmp 0b,$deffile + bne 5f + mov $1,r0 + sys write; ttyc; 3 +5: + mov $1,r0 + sys write; spsp; 2 + mov utmp+12.,mq + mov utmp+10.,ac + mov $1,r0 + jsr pc,prdate + mov $1,r0 + sys write; nl; 1 + br 2b + +error: + mov $1,r0 + sys write; errmsg; 2 +done: + sys exit + +blank: < > +ttyc: +ttyno = ttyc+3 +spsp: < > +deffile: +0: + .even +nl: <\n> +utmp: .=.+16. + +prdate: + mov r1,-(sp) + sub $16.,sp + mov r0,r1 + mov sp,r0 + jsr pc,fmtdate + mov r0,0f + mov r1,r0 + sys write; 0:..; 17. + add $16.,sp + mov (sp)+,r1 + rts pc + +fmtdate: + mov r2,-(sp) + mov r3,-(sp) + cmp ac,yrdays + blo 1f + bhi 2f + cmp mq,yrdays+2 + blo 1f +2: + mov ac,-(sp) + sub yrdays+2,mq + sbc (sp) + sub yrdays,(sp) + mov (sp)+,ac + mov $29.,daylen +1: + mov $-4,lsh + mov $26300.,div + mov mq,r3 + mov ac,mq + mov $2,lsh + mov $17.,div + add $17.,r0 + jsr r5,digit; 10. + jsr r5,digit; 6 + movb $':,-(r0) + jsr r5,digit; 10. + jsr r5,digit; 6 + movb $':,-(r0) + mov r3,mq + mov $24.,div + mov mq,r3 + mov ac,mq + jsr r5,digit; 10. + jsr r5,digit; 10. + mov $montab,r2 +1: + cmp (r2),r3 + bgt 2f + sub (r2)+,r3 + br 1b +2: + movb $' ,-(r0) + sub $montab,r2 + asl r2 + add $months,r2 + inc r3 + mov r3,mq + jsr r5,digit; 10. + tst mq + beq 1f + add $'0,mq + movb mq,-(r0) + br 2f +1: + movb $' ,-(r0) +2: + movb $' ,-(r0) + movb -(r2),-(r0) + movb -(r2),-(r0) + movb -(r2),-(r0) + mov (sp)+,r3 + mov (sp)+,r2 + rts pc + +digit: + clr ac + mov (r5)+,div + add $'0,ac + movb ac,-(r0) + rts r5 + +yrdays: 57544.; 4480. +daylen: 31.; 28.; 31.; 30.; 31.; 30.; 31.; 31.; 30.; 31.; 30. +montab = .-2 +months: + < \0Jan\0Feb\0Mar\0Apr\0May\0Jun\0Jul\0Aug\0Sep\0Oct\0Nov\0Dec\0> + .even + +errmsg: -- 2.51.0 From tuhs at tuhs.org Sat Jan 17 08:28:56 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 16 Jan 2026 22:28:56 +0000 Subject: [TUHS] Possible Assembly UNIX Kernel Images (s1-bits cunix/wunix)? In-Reply-To: References: Message-ID: Thank you so much Briam! I'll be sitting down to look more at the two kernels later and will get this merged into v2src as well. Fittingly I have a house call to fix an old WECo phone so have to break from the excitement for a few hours. Do you have a preference on how I credit you for this work in the README? - Matt G. On Friday, January 16th, 2026 at 14:11, Briam Rodriguez via TUHS wrote: > Hi Matt, > > Saw your post about the v2src restoration project. I took a crack at > disassembling the remaining binaries from the s2-bits tape - > specifically the bin/ directory utilities. > > I've got 26 commands disassembled and formatted to match your existing > style conventions: > > as, bas, cc, db, dc, ds, du, ed, fc, find, form, ld, maki, mv, nm, od, > pr, roff, size, sort, stat, tap, tm, un, wc, who > > They're ready as a patch file. Please find it attached. I tried creating > a PR on gitlab but it wouldn't let me due to auth issues. > > Happy to help with more disassembly work if there are other artifacts > worth looking at. > > -- Briam R. > > On 1/16/26 5:06 PM, segaloco via TUHS wrote: > > > Hello everyone, I've been picking back up on some of my V2/V3 era > > reverse engineering efforts, picking through stuff from the Dennis_Tapes > > archive, and I came across something I don't think I've seen discussed. > > > > On the s1 tape, which we've yoinked a lot of V3 userland sources from, > > there are files cunix and wunix. Upon some disassembly and inspection, > > I believe these may be assembly UNIX kernels, although I haven't dug > > around too much to see what version they match most closely. Here are > > some findings that support my suspicions: > > > > - Both files begin with a 407 magic number, making them V2 a.out > > binaries. > > - Both begin with a branch that jumps over a few things then calls a > > subroutine. That subroutine matches "copyz" from u3.s in the scanned > > V1 kernel description from BTL. Indeed this jump in that kernel is also > > to copyz. > > > > Of course, this is only the first few bits executed, but I would be > > surprised to find such a close match elsewhere in the system. I do this > > sort of analysis on old video game code all the time, so I feel pretty > > confident in identifying these as possible assembly-era kernels. > > > > Anyone dug around in these before? These should be PDP-11/20 kernels as > > I'm finding plenty of EAE references, just like the s2-bits V2 binaries. > > What I'm hoping to find here are bits that might indicate KS11 support, > > what with the recent chit chat about KS11 in the V2 kernel. > > > > - Matt G. From tuhs at tuhs.org Sat Jan 17 10:50:11 2026 From: tuhs at tuhs.org (Briam R via TUHS) Date: Fri, 16 Jan 2026 19:50:11 -0500 Subject: [TUHS] Possible Assembly UNIX Kernel Images (s1-bits cunix/wunix)? In-Reply-To: References: Message-ID: <04F03636-D2C4-48DD-94D3-5772BD90F80A@gmail.com> No sir! Any mention is a good mention, I’m just glad to be here amongst such esteemed company! — Briam R. ————————— > On Jan 16, 2026, at 5:29 PM, segaloco via TUHS wrote: > > Thank you so much Briam! I'll be sitting down to look more at the two > kernels later and will get this merged into v2src as well. Fittingly I > have a house call to fix an old WECo phone so have to break from the > excitement for a few hours. Do you have a preference on how I credit > you for this work in the README? > > - Matt G. > >> On Friday, January 16th, 2026 at 14:11, Briam Rodriguez via TUHS wrote: >> >> Hi Matt, >> >> Saw your post about the v2src restoration project. I took a crack at >> disassembling the remaining binaries from the s2-bits tape - >> specifically the bin/ directory utilities. >> >> I've got 26 commands disassembled and formatted to match your existing >> style conventions: >> >> as, bas, cc, db, dc, ds, du, ed, fc, find, form, ld, maki, mv, nm, od, >> pr, roff, size, sort, stat, tap, tm, un, wc, who >> >> They're ready as a patch file. Please find it attached. I tried creating >> a PR on gitlab but it wouldn't let me due to auth issues. >> >> Happy to help with more disassembly work if there are other artifacts >> worth looking at. >> >> -- Briam R. >> >>> On 1/16/26 5:06 PM, segaloco via TUHS wrote: >>> >>> Hello everyone, I've been picking back up on some of my V2/V3 era >>> reverse engineering efforts, picking through stuff from the Dennis_Tapes >>> archive, and I came across something I don't think I've seen discussed. >>> >>> On the s1 tape, which we've yoinked a lot of V3 userland sources from, >>> there are files cunix and wunix. Upon some disassembly and inspection, >>> I believe these may be assembly UNIX kernels, although I haven't dug >>> around too much to see what version they match most closely. Here are >>> some findings that support my suspicions: >>> >>> - Both files begin with a 407 magic number, making them V2 a.out >>> binaries. >>> - Both begin with a branch that jumps over a few things then calls a >>> subroutine. That subroutine matches "copyz" from u3.s in the scanned >>> V1 kernel description from BTL. Indeed this jump in that kernel is also >>> to copyz. >>> >>> Of course, this is only the first few bits executed, but I would be >>> surprised to find such a close match elsewhere in the system. I do this >>> sort of analysis on old video game code all the time, so I feel pretty >>> confident in identifying these as possible assembly-era kernels. >>> >>> Anyone dug around in these before? These should be PDP-11/20 kernels as >>> I'm finding plenty of EAE references, just like the s2-bits V2 binaries. >>> What I'm hoping to find here are bits that might indicate KS11 support, >>> what with the recent chit chat about KS11 in the V2 kernel. >>> >>> - Matt G. From tuhs at tuhs.org Sat Jan 17 10:59:39 2026 From: tuhs at tuhs.org (Yufeng Gao via TUHS) Date: Sat, 17 Jan 2026 00:59:39 +0000 Subject: [TUHS] Possible Assembly UNIX Kernel Images (s1-bits cunix/wunix)? In-Reply-To: References: Message-ID: Hi,     > Anyone dug around in these before? I've dug a tiny bit into these kernels early last year: https://www.tuhs.org/pipermail/tuhs/2025-February/031420.html https://www.tuhs.org/pipermail/tuhs/2025-February/031423.html There's no KS11 support, otherwise it wouldn't boot under emulation. Sincerely, Yufeng From tuhs at tuhs.org Sat Jan 17 10:59:53 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 17 Jan 2026 00:59:53 +0000 Subject: [TUHS] Possible Assembly UNIX Kernel Images (s1-bits cunix/wunix)? In-Reply-To: References: Message-ID: Hmm, Briam, might I ask what your process was? I'm finding quite a few discrepancies, for instance, when I put this copy of as(I) through a PDP-11 disassembler, I get an entry something like (syscalls filled in): 000020: 000167 016316 jmp 16342 ; w.N. ; 000024: 004767 000632 jsr r7,662 ; w... 000030: 116700 011562 movb 11616,r0 ; @.r. 000034: 104404 sys write; $52614; 1000 000042: 116700 011550 movb 11616,r0 ; @.h. 000046: 104406 sys close ; .. 000050: 116700 011545 movb 11621,r0 ; @.e. 000054: 104406 sys close ; .. 000056: 105767 005466 tstb 5550 ; w.6. 000062: 001041 bne 166 ; !. 000064: 004567 000230 jsr r5,320 ; w... But this same chunk of your as.s you sent: / start of program start: jmp main / error handling error: jsr pc,pass1 movb errflg,r0 sys creat; tmpf1; 1000 movb errflg,r0 sys creat; tmpf2; 0 movb passno,r0 tstb dotflg bne 1f jsr r5,errstr <-e\n\0>; .even I'm really confused where those creat's came from, whats going on there is quite different than what you sent me. The former, what I got out of my own disassembly of the file, matches as11.s in both V2 and V5. I have my doubts this entrypoint changed that much between V2 and V5 only to wind up the same again in V5. Are we working from two different sets of binaries? I just want to make sure before I put much more time into aligning these with known V2 and V5 sources. My goal for the v2src repository is that it should diff appropriately with known, real sources, that's one of my quality gates I'm applying here. - Matt G. On Friday, January 16th, 2026 at 14:11, Briam Rodriguez via TUHS wrote: > Hi Matt, > > Saw your post about the v2src restoration project. I took a crack at > disassembling the remaining binaries from the s2-bits tape - > specifically the bin/ directory utilities. > > I've got 26 commands disassembled and formatted to match your existing > style conventions: > > as, bas, cc, db, dc, ds, du, ed, fc, find, form, ld, maki, mv, nm, od, > pr, roff, size, sort, stat, tap, tm, un, wc, who > > They're ready as a patch file. Please find it attached. I tried creating > a PR on gitlab but it wouldn't let me due to auth issues. > > Happy to help with more disassembly work if there are other artifacts > worth looking at. > > -- Briam R. > > On 1/16/26 5:06 PM, segaloco via TUHS wrote: > > > Hello everyone, I've been picking back up on some of my V2/V3 era > > reverse engineering efforts, picking through stuff from the Dennis_Tapes > > archive, and I came across something I don't think I've seen discussed. > > > > On the s1 tape, which we've yoinked a lot of V3 userland sources from, > > there are files cunix and wunix. Upon some disassembly and inspection, > > I believe these may be assembly UNIX kernels, although I haven't dug > > around too much to see what version they match most closely. Here are > > some findings that support my suspicions: > > > > - Both files begin with a 407 magic number, making them V2 a.out > > binaries. > > - Both begin with a branch that jumps over a few things then calls a > > subroutine. That subroutine matches "copyz" from u3.s in the scanned > > V1 kernel description from BTL. Indeed this jump in that kernel is also > > to copyz. > > > > Of course, this is only the first few bits executed, but I would be > > surprised to find such a close match elsewhere in the system. I do this > > sort of analysis on old video game code all the time, so I feel pretty > > confident in identifying these as possible assembly-era kernels. > > > > Anyone dug around in these before? These should be PDP-11/20 kernels as > > I'm finding plenty of EAE references, just like the s2-bits V2 binaries. > > What I'm hoping to find here are bits that might indicate KS11 support, > > what with the recent chit chat about KS11 in the V2 kernel. > > > > - Matt G. From tuhs at tuhs.org Sat Jan 17 11:22:09 2026 From: tuhs at tuhs.org (Angelo Papenhoff via TUHS) Date: Sat, 17 Jan 2026 02:22:09 +0100 Subject: [TUHS] UNIX v4 Source Code Commentary - complete book now available In-Reply-To: References: Message-ID: So i tried v4 on my own pdp11/40 emulator [1] and there it seems to work fine (after i fixed a bug in the RK controller). So i guess this is a simh bug? aap [1] https://github.com/aap/pdp11 On 15/01/26, Angelo Papenhoff via TUHS wrote: > Looks very nice, thanks! > > I was wondering about the RK driver, because there are issues with it. > The v4 RK11 driver does not work with simh emulation correctly when > using multiple disks. I've had to use the v5 driver for my v4 > installation guide to get a usable system. Looking at the code i had the > impression that the v4 driver is fine (it also matches the nsys RK > driver, which i've also had trouble with recently. haven't tried v5 RK > with nsys yet). What i suspect is happening is that the seek/read dance > isn't working correctly, either in simh, or there were faulty > assumptions that only work on real hardware more or less accidentially > (the rewrite in v5 might suggest the latter). > In any case it looks like blocks aren't being read correctly, and > whatever process is waiting for the read will hang. > > Would be nice to get to the bottom of this. > > cheers, > aap > > On 12/01/26, Briam Rodriguez via TUHS wrote: > > Hello, > > > > Following the incredible recovery of the UNIX v4 tape from the University > > of Utah last month, I've written a comprehensive line-by-line commentary > > on the entire UNIX Fourth Edition source code. > > > > The book covers: > > - The kernel (boot, processes, memory management, scheduling) > > - The file system (inodes, buffer cache, namei) > > - Device drivers (TTY, RK05 disk, character devices) > > - User space (shell, utilities, C compiler, assembler) > > - Plus appendices with system call reference, file formats, and PDP-11 guide > > > > It's open source (CC BY-NC-SA 4.0) and available on GitHub: > > > > https://github.com/unix-v4-commentary/unix-v4-source-commentary > > > > The PDF is included in the repo for those who just want to read. > > > > It is my sincerest hope that this book can help someone, and I'd > > appreciate any feedback (and changes!). > > > > Many thanks to Robert Ricci, and Al Kossow, and everyone involved in > > recovering this historic code. > > > > Without that work, this book wouldn't have been possible. Also thanks to > > Mr. Warren for letting me in to the mailing list! > > > > Please don't beat me up too bad! > > > > Humbly yours, > > > > Briam Rodriguez > > From tuhs at tuhs.org Sun Jan 18 01:46:18 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Sat, 17 Jan 2026 10:46:18 -0500 Subject: [TUHS] Possible Assembly UNIX Kernel Images (s1-bits cunix/wunix)? In-Reply-To: References: Message-ID: Matt, Sorry about that! I made errors in my syscall identification process - the structure looked roughly correct but the actual trap numbers were wrong. Your disassembly showing sys write and sys close are correct; mine had sys creat which doesn't match the opcodes at all. Please disregard that patch, seems I was a bit too hasty to contribute! I've since built out a proper validation workflow: assemble with the actual V2 toolchain via Apout, then byte-compare against the original binary. If it's not identical, it's not done. As proof of concept - while validating this process against your existing sources, I found a 1-byte discrepancy in strip.s at offset 0xF4. The bne 1b branch target was wrong because the 1: label was placed before the size calculation rather than before the cmp r2,r3. The original binary's inner loop only re-checks the comparison. I can send you the fix if you'd like - it now assembles to byte-identical output. I'll send properly-validated reconstructions once I've worked through the kinks! -- Briam On 1/16/26 7:59 PM, segaloco via TUHS wrote: > Hmm, Briam, might I ask what your process was? I'm finding quite a few > discrepancies, for instance, when I put this copy of as(I) through a > PDP-11 disassembler, I get an entry something like (syscalls filled in): > > 000020: 000167 016316 jmp 16342 ; w.N. > ; > 000024: 004767 000632 jsr r7,662 ; w... > 000030: 116700 011562 movb 11616,r0 ; @.r. > 000034: 104404 sys write; $52614; 1000 > 000042: 116700 011550 movb 11616,r0 ; @.h. > 000046: 104406 sys close ; .. > 000050: 116700 011545 movb 11621,r0 ; @.e. > 000054: 104406 sys close ; .. > 000056: 105767 005466 tstb 5550 ; w.6. > 000062: 001041 bne 166 ; !. > 000064: 004567 000230 jsr r5,320 ; w... > > But this same chunk of your as.s you sent: > > / start of program > start: > jmp main > > / error handling > error: > jsr pc,pass1 > movb errflg,r0 > sys creat; tmpf1; 1000 > movb errflg,r0 > sys creat; tmpf2; 0 > movb passno,r0 > tstb dotflg > bne 1f > jsr r5,errstr > <-e\n\0>; .even > > I'm really confused where those creat's came from, whats going on there > is quite different than what you sent me. The former, what I got out of > my own disassembly of the file, matches as11.s in both V2 and V5. I > have my doubts this entrypoint changed that much between V2 and V5 only > to wind up the same again in V5. > > Are we working from two different sets of binaries? I just want to make > sure before I put much more time into aligning these with known V2 and > V5 sources. My goal for the v2src repository is that it should diff > appropriately with known, real sources, that's one of my quality gates > I'm applying here. > > - Matt G. > > On Friday, January 16th, 2026 at 14:11, Briam Rodriguez via TUHS wrote: > >> Hi Matt, >> >> Saw your post about the v2src restoration project. I took a crack at >> disassembling the remaining binaries from the s2-bits tape - >> specifically the bin/ directory utilities. >> >> I've got 26 commands disassembled and formatted to match your existing >> style conventions: >> >> as, bas, cc, db, dc, ds, du, ed, fc, find, form, ld, maki, mv, nm, od, >> pr, roff, size, sort, stat, tap, tm, un, wc, who >> >> They're ready as a patch file. Please find it attached. I tried creating >> a PR on gitlab but it wouldn't let me due to auth issues. >> >> Happy to help with more disassembly work if there are other artifacts >> worth looking at. >> >> -- Briam R. >> >> On 1/16/26 5:06 PM, segaloco via TUHS wrote: >> >>> Hello everyone, I've been picking back up on some of my V2/V3 era >>> reverse engineering efforts, picking through stuff from the Dennis_Tapes >>> archive, and I came across something I don't think I've seen discussed. >>> >>> On the s1 tape, which we've yoinked a lot of V3 userland sources from, >>> there are files cunix and wunix. Upon some disassembly and inspection, >>> I believe these may be assembly UNIX kernels, although I haven't dug >>> around too much to see what version they match most closely. Here are >>> some findings that support my suspicions: >>> >>> - Both files begin with a 407 magic number, making them V2 a.out >>> binaries. >>> - Both begin with a branch that jumps over a few things then calls a >>> subroutine. That subroutine matches "copyz" from u3.s in the scanned >>> V1 kernel description from BTL. Indeed this jump in that kernel is also >>> to copyz. >>> >>> Of course, this is only the first few bits executed, but I would be >>> surprised to find such a close match elsewhere in the system. I do this >>> sort of analysis on old video game code all the time, so I feel pretty >>> confident in identifying these as possible assembly-era kernels. >>> >>> Anyone dug around in these before? These should be PDP-11/20 kernels as >>> I'm finding plenty of EAE references, just like the s2-bits V2 binaries. >>> What I'm hoping to find here are bits that might indicate KS11 support, >>> what with the recent chit chat about KS11 in the V2 kernel. >>> >>> - Matt G. From tuhs at tuhs.org Sun Jan 18 08:38:46 2026 From: tuhs at tuhs.org (Nelson H. F. Beebe via TUHS) Date: Sat, 17 Jan 2026 15:38:46 -0700 Subject: [TUHS] Utah Unix V4 tape in podcast Message-ID: The 15-Jan-2026 episode #646 of the BSD Now podcast headline story is about the Unix V4 tape recently discovered in Utah: https://www.bsdnow.tv/646 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: https://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From tuhs at tuhs.org Mon Jan 19 00:44:30 2026 From: tuhs at tuhs.org (Diomidis Spinellis via TUHS) Date: Sun, 18 Jan 2026 16:44:30 +0200 Subject: [TUHS] Reproducible builds in the Seventh Research Edition Message-ID: <1cb7828d-dbee-42b6-ae6c-a2fcf821b533@aueb.gr> I noticed that most makefiles in the Seventh Research Edition Unix /usr/src/cmd directory contain two non-default rules: *cp* to build and copy the executable file to its destination and *cmp* to build and compare the executable against its destination. Both then delete the object and executable files. Here's an example from awk [1]. all: awk cp: awk cp awk /bin/awk rm *.o awk.h proc awk proctab.c y.tab.h cmp: awk cmp awk /bin/awk rm *.o awk.h proc awk proctab.c y.tab.h Does anyone know the main reason for the *cmp* rule? Was it to check that the source code matched the system's executable; to check that an updated compiler still produced the same executable; or to check against disk corruption? In any case, it appears that in the 1970s Unix supported reproducible builds, a property that got lost as build tool chains got more complex and became a thing decades later [2]. [1] https://github.com/dspinellis/unix-history-repo/blob/Research-V7/usr/src/cmd/awk/makefile [2] https://en.wikipedia.org/wiki/Reproducible_builds Diomidis - https://www.spinellis.gr From tuhs at tuhs.org Mon Jan 19 02:08:23 2026 From: tuhs at tuhs.org (William H. Mitchell via TUHS) Date: Sun, 18 Jan 2026 09:08:23 -0700 Subject: [TUHS] CCI POWER 6/32 | Harris HCX-[579] | Unisys 7000/40 In-Reply-To: References: <20260115132444.56D0618C087@mercury.lcs.mit.edu> Message-ID: <5A1537F4-4B21-4406-9153-CB03BED8F75F@msweng.com> We took a pretty close look at the CCI 6/32 vs. the VAX 8600 as a main departmental machine for U of Arizona CS in 1984 or so. I remember then-department head Dave Hanson saying that "research" (Bell Labs' uucp name) had a gotten a 6/32 and "they named it ’thunder’". Our benchmarks on the 6/32 showed that "thunder" was justified but we ended up waiting on the 8600, which turned out to be a great machine. This is getting further OT but when the UA computer center replaced a VAX 78X running VMS with an 8600 they started getting calls from users saying that some DCL commands weren’t working. It turned out that the 8600 was so much faster than the 78X that when one hit ENTER, the next prompt seemed to immediately appear, as if the command line had been ignored. > On Jan 15, 2026, at 6:54 AM, Marc Donner via TUHS wrote: > > Thank you, Noel! > > ===== > mindthegapdialogs.com > north-fork.info > > On Thu, Jan 15, 2026, 08:25 Noel Chiappa via TUHS wrote: > >>> From: Marc Donner >> >>> A colleague asked for this manual: >>> "Does anyone have an architecture manual / processor manual ... for >>> this system, for the CCI POWER 6/32 (or any of it's rebadgings >> >> If one (or _anything_) turns up, it's _crucial_ that it be scanned, and the >> scans sent to Bitsavers!!! Almost nothing is known of this >> historically-important machine - the first thing other than a VAX that BSD >> was ported to. >> >> >> I did a fair amount of scratching around, and starting with the toolchain >> (mostly the debugger), which still exists, I was able to retrieve enough to >> give us a decent idea of the machine: >> >> https://gunkies.org/wiki/Power_6/32 >> >> There was discussion of trying to create an emulator, from the info in >> the toolchain: >> >> https://gunkies.org/wiki/Talk:Power_6/32 >> >> I was able to work out, from the instruction decode stuff in the debugger, >> what the instructions look like (fields, etc): but that still doesn't tell >> us what all the instructions _do_, at the level of detail that would be >> needed >> for successful emulation. We'd really need that manual! >> >> There is also "Installing and Operating BSD UNIX on the Tahoe", linked from >> the above. >> >> Noel >> From tuhs at tuhs.org Mon Jan 19 18:38:56 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Mon, 19 Jan 2026 19:38:56 +1100 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: References: <792DD77D-8BEB-4CC9-AFE6-F92C2F73BB1F@planet.nl> Message-ID: On Tue, Jan 13, 2026 at 12:21:25PM +1100, Jonathan Gray via TUHS wrote: > On Sun, Jan 11, 2026 at 11:21:39PM +0100, Paul Ruizendaal via TUHS wrote: > > Jonathan Gray very kindly found two sources for “yopti” in the TUHS archives. > > > > The first is in the UNSW 110 archive (https://www.tuhs.org/Archive/Distributions/UNSW/110/). The archive is from 1981, but it appears to be the 1975 yacc of 6th edition. > > > > This yacc has the source for the optimizer ("yopti.c”). It reads the the y.tab.c file that plain 6th edition yacc generates, does some processing and writes out a new y.tab.c. It also comes with a new yyparse routine and this routine is essentially identical to the yyparse of 7th edition (which I think is more or less the final version of classic yacc). > > > > The other is in the PWB1 distribution (https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s2/yacc.d), from 1977. The optimizer is now in the source file "y5.c” and largely, but not fully the same. It has a new way to compress the “yyact” table. The y5.c file can build both as a separate program and as a subroutine of the yacc core, reusing table space from the earlier phases. The new way to compress is also used in 7th edition, but the optimizer has been fully integrated in the core yacc codebase. > > Also appears (without source) in a listing of files. > > Documentation/TechReports/USG_Library/ > 1046_UNIX_Support_Classifications_for_PG_1C300_Issue_2.pdf > > UNIX Support Classifications for PG-1C300-1 Issue 2 > January 30, 1976 > > opar.c yacc optimization parser > yopti.c yacc optimizer postpass > > > All in all, my hypothesis on the timeline would now be: > > > > - 1971: first version of yacc created in B "yacc was written in 1972" Stephen C. Johnson interview in The C Journal, Vol 3, No 2, Fall 1987, p 58 https://archive.org/details/the-c-journal-v-3-n-2-1987-fall/page/n63/mode/1up > > - 1972: improvements to make it more practical > > - 1973: yacc introduced to Waterloo (relevant for Eh) > > Unix Programmer's Manual, Third Edition, February 1973 > YACC (VI) 1/20/73 > mentions /crp/scj/bpar.b, output tables in actn.b > > "If your grammar is too big for yacc, you may try /crp/scj/bigyacc" > > > - 1973: conversion from B to C > > Unix Programmer's Manual, Fourth Edition, November 1973 > YACC (VI) 6/6/73 > no longer mentions b files > > > - 1974: improvements on speeding up table generation > > Unix Programmer's Manual, Sixth Edition, May 1975 > YACC (I) 11/25/74 > > /usr/yacc/opar.c parser for optimized tables > /usr/yacc/yopti optimizer postpass > > > - 1975: improvements on speeding up yyparse execution > > - 1976: improvement on reducing optimized table size > > - 1977/78: cleaning up code base, portability, tracking C changes > > - 1979: more or less final version of classic yacc > > > > The above matches with interviews with Johnson and Aho, where both say that yacc was improved over a number of years and with about a dozen rewrites in that period. From tuhs at tuhs.org Tue Jan 20 05:23:52 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Mon, 19 Jan 2026 14:23:52 -0500 Subject: [TUHS] RK overlapped seek emulation issue in Unix v4 In-Reply-To: <174a0347-9c2d-4b04-8739-c13a86ea0d67@supnik.org> References: <66bf48c5-c848-4da5-a287-8a8a5b30f1f3@supnik.org> <2729c68c-a497-45e9-8835-de06968262b6@supnik.org> <174a0347-9c2d-4b04-8739-c13a86ea0d67@supnik.org> Message-ID: Is the test just booting Unix v4 with the new code? Assuming your code is in V3 of SIMH, I’ll need rebuild your tree with the code. But I’ll happy to test it Sent from a handheld expect more typos than usual On Mon, Jan 19, 2026 at 2:09 PM Bob Supnik wrote: > I have a new version of the RK emulator, which I think straightens out > the overlapped seeks. I've run quick regressions on RT V4, Unix v5, and > RSTS/E V10, to show that I didn't break any existing behavior. Before > releasing it, though, I'd like to run a specific test on overlapped seek > behavior, without having to debug in Unix v4. My PDP11 coding skills are > rather rusty, so if anyone wants to take a crack at writing a specific > test, feel free. > > The changes are in the V3 source, so they would have to be transposed to > V4. > > On 1/16/2026 11:21 AM, Bob Supnik wrote: > > Okay, I don't think the impact is as bad as I feared. The use of a > > single word queue, rkintq, to maintain the controller and seek > > interrupt flags, is probably okay. But in the current code, it is > > cleared too aggressively and not set in some circumstances. > > > > I see four changes required. > > > > 1. rkcsr write > > > > - If clearing IE, clear the controller interrupt flag and the > > interrupt request itself, but not the seek interrupt flags. > > - If setting IE, > > > If RDY = 1, and previous RDY = 0, then set the controller > > interrupt flag. > > > Regardless, if the interrupt queue is non-zero, set interrupt > > request. This picks up any pending seek interrupts. > > > > 2. Operation initiation for any function that requires head motion > > (that is, not control reset or set write lock) > > - Clear the drive's seek interrupt flag and the controller interrupt > > flag. > > - Clear the interrupt request, because the controller will not > > interrupt if it is busy. > > > > 3. Seek complete > > - Set the drive's interrupt flag unconditionally, whether IE is set or > > clear. > > - If IE is set, and the controller is not busy (RDY = 1), set > > interrupt request. > > > > 4. Set done > > - Change the IE = 0 case to just clear the controller interrupt flag, > > as well as the interrupt request. Do not change the seek interrupt flags. > > > > The interrupt acknowledge routine is okay. It acknowledges controller > > interrupts first. If a seek interrupt, it knocks down the request and > > sets the drive ID. > > > > So with these changes, if three drive seek interrupts get queued, they > > will be serviced one at a time, after any controller interrupt. They > > are not cleared, unless the controller is reset or a new operation is > > initiated on that drive. As noted in the maintenance documentation, > > the interrupt service routine must run at IPL 5 or higher; otherwise, > > the seek interrupts will occur one right after another. > > > > There may be problems in the detailed status flags. It would be useful > > to see the source code for the driver. > > > > Note that all this analysis has been done on the v3 source code. I > > don't think v4 changed much except to add debug features. > > > > Bob Supnik > > > > On 1/16/2026 9:03 AM, Bob Supnik wrote: > >> I don't think this logic has ever been tested before, because no DEC > >> OS, and no previously available versions of Unix, used it. > >> > >> Going back to it after 30+(!) years, it certainly looks a suspect, > >> primarily because the entire interrupt queue - controller plus seeks > >> - is cleared whenever the simulator sees that RKCSR is clear. > >> This would cause seek interrupts to be lost. > >> > >> The controller logic changed quite a bit between the original RK11C > >> and the more common RK11D, but the descriptions are similar. The > >> controller has eight MASK flops, one for each drive. These are set > >> when the controller initiates a SEEK (or DRIVE RESET, in effect a > >> seek) on a drive. The poll logic is active whenever RKCSR is > >> set, that is, the controller is idle. It monitors the MASK bits and > >> the seek done signal from the drive. If both are set, RKCSR is > >> set, and an interrupt is not already pending, it generates an > >> interrupt request. If I look at the RK11D schematics, the mask flops > >> are mass cleared only by a controller reset pulse; no other time. > >> > >> Tl;dr. The implementation of overlapped seeks is wrong, in several > >> respects. Fixing it may require a significant rewrite. Ugh! > >> > >> Bob Supnik > >> > >> > >> > > > > From tuhs at tuhs.org Tue Jan 20 05:44:50 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Mon, 19 Jan 2026 11:44:50 -0800 Subject: [TUHS] history of virtual address space Message-ID: I was trying to remember how virtual address space evolved in Unix. When I joined the game in v6 days, processes had virtual 0->0xffff, with the potential for split I/D IIRC, getting you that bit of extra space. The kernel also had virtual 0->0xffff, also with split I/D. The kernel accessed user data with mov/load from previous address space instructions. But also on the 11, trap vectors chewed up a chunk of low physical memory, and the diode ROM took out some chunk of high physical. The bootstrap you set from the front panel started with many 1's. Later, when we had bigger address spaces on 32- bit systems, page 0 was made unavailable in users address space to catch NULL pointers. Did that happen on the VAX at some point, or later? Later we got the "kernel is high virtual with bit 31 set" -- when did that first happen? At some point, the conventions solidify, in the sense that kernels have high order bits all 1s, and user has page 0x200000 and up; and user mode does not get any virtual address with high order bit set. My rough memory is that this convention became most common in the 90s. So, for the pre-mmu Unix, what addresses did processes get, as opposed to the kernel? Did the kernel get loaded to, and run from, high physical? Did processes get memory "above trap vectors" and below the kernel? For the era of MMUs, I kmow the data general 32-bit systems put user memory in "high virtual", which turned out to be really painful, as so many Unix programs used address 0 (unknown to their authors!). What other Unix systems used a layout where the kernel was in low virtual? I'm not even sure where to find these answers, so apologies in advance for the questions. From tuhs at tuhs.org Tue Jan 20 06:06:47 2026 From: tuhs at tuhs.org (brantley coile via TUHS) Date: Mon, 19 Jan 2026 15:06:47 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: <77FE267A-72C5-4FB7-9A23-E58021F6975F@coraid.com> We got first edition Unix working some years ago. The user program was loaded at orig = 0 . core = orig+40000 That's octal so 16k. I did a port of Seventh Edition where I put the kernel and user programs at zero. That was a mistake. That was in 1986. I then moved the user program to 4K and the kernel to 0x80000000. I got that from BSD. Don't know if it was the first. Maybe you could peep at 32V, but I'm sure it loads the kernel at 1<31. It's how the VAX hardware works, if I'm not mistaken. https://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUnixImplementationDocument_Jun72.pdf bwc > On Jan 19, 2026, at 2:44 PM, ron minnich via TUHS wrote: > > I was trying to remember how virtual address space evolved in Unix. > > When I joined the game in v6 days, processes had virtual 0->0xffff, with > the potential for split I/D IIRC, getting you that bit of extra space. The > kernel also had virtual 0->0xffff, also with split I/D. The kernel > accessed user data with mov/load from previous address space instructions. > But also on the 11, trap vectors chewed up a chunk of low physical memory, > and the diode ROM took out some chunk of high physical. The bootstrap you > set from the front panel started with many 1's. > > Later, when we had bigger address spaces on 32- bit systems, page 0 was > made unavailable in users address space to catch NULL pointers. Did that > happen on the VAX at some point, or later? > > Later we got the "kernel is high virtual with bit 31 set" -- when did that > first happen? > At some point, the conventions solidify, in the sense that kernels have > high order bits all 1s, and user has page 0x200000 and up; and user mode > does not get any virtual address with high order bit set. My rough memory > is that this convention became most common in the 90s. > > So, for the pre-mmu Unix, what addresses did processes get, as opposed to > the kernel? Did the kernel get loaded to, and run from, high physical? Did > processes get memory "above trap vectors" and below the kernel? > > For the era of MMUs, I kmow the data general 32-bit systems put user memory > in "high virtual", which turned out to be really painful, as so many Unix > programs used address 0 (unknown to their authors!). What other Unix > systems used a layout where the kernel was in low virtual? > > I'm not even sure where to find these answers, so apologies in advance for > the questions. From tuhs at tuhs.org Tue Jan 20 08:33:05 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Mon, 19 Jan 2026 17:33:05 -0500 (EST) Subject: [TUHS] history of virtual address space Message-ID: <20260119223305.EC0DF18C077@mercury.lcs.mit.edu> > From: Ron Minnich via TUHS tuhs at tuhs.org > on the 11, trap vectors chewed up a chunk of low physical memory I don't think so: I have a note that "Trap and interrupt vectors are fetched from Kernel Data space, when memory management is enabled" (can't cite a manual page, sorry, but I'm pretty sure that's right). So they could be anywhere, physically. Of course, in UNIX, Kernel Data space is at physical 0, so in _practice_, in UNIX, they are in low physical memory. Actually, there's: #define B_RELOC 0200 /* no longer used */ in buf.h, and I have a vague memory of reading that at same point, buffers' physical address was _not_ the same as their virtual addresses (which is what all the hair with 'sysfix', etc, is needed to do), so who knows if that was always true (if buffers were not always in low physical memory). > What other Unix systems used a layout where the kernel was in low > virtual? In MINI-UNIX, user programs are loaded and run at 060000; the kernel was in low memory. (Probably LSX too, but I don't know much about that.) Not sure if that's what you meant! Noel From tuhs at tuhs.org Tue Jan 20 08:46:43 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Mon, 19 Jan 2026 22:46:43 +0000 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: The original UNIX PDP-11 address space (and this remained constant throughout the years) started at location 0 and went up by 64 byte chunks. This was done in seven of the eight segments the PDP-11 hardware did. The stack started in the last one and went downward (again in 64 byte chunks) from the top of the 16-bit address space. If you were running in 407 mode, it was all the same as far as code and data. All writable. In 410 mode (pure text), the segments containing the code were write protected against the user (this also allowed them to be shared between instances of the program and even locked in swap with the sticky bit). A 411 (on hardware that supported it) split the code and data segments into separate segments. You couldn’t even access the code as data on the user side (thwarting the nargs function). The kernel ran mostly mapped to physical address. However, the user structure of the current running process was kept in the high segment. When we went to Vax, pretty much the same idea was kept (programs started at location zero and grew up). Some moron decided not only to start at zero, but put a 0 at location 0 which led to lots of latent bugs. Later when we got the Gould SELs in we had page zero unmapped to catch null pointer access, but some programs we didn’t have source to (notably Oracle) still expected to access *0 with impunity, so we added a flag we could poke into the header called “braindead vax compatibility mode” that mapped a zero at zero for these programs. Things got even stranger when we ported to the HEP which had four kinds of memory From tuhs at tuhs.org Tue Jan 20 09:10:59 2026 From: tuhs at tuhs.org (Luther Johnson via TUHS) Date: Mon, 19 Jan 2026 16:10:59 -0700 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: I once found an old version of RCS that expected *0 = 0, and I think many other programs did as well. I'm not sure which versions of Unix did or still do this any more, but I believe many had the first page in virtual address space for user program processes, mapped to a read-only page of zeroes, to support this. If I'm remembering that wrong, I'm interested as the other posters here are, in the details of which did which sorts of things. On 01/19/2026 03:46 PM, Ron Natalie via TUHS wrote: > The original UNIX PDP-11 address space (and this remained constant > throughout the years) started at location 0 and went up by 64 byte > chunks. This was done in seven of the eight segments the PDP-11 > hardware did. The stack started in the last one and went downward > (again in 64 byte chunks) from the top of the 16-bit address space. > If you were running in 407 mode, it was all the same as far as code > and data. All writable. > In 410 mode (pure text), the segments containing the code were write > protected against the user (this also allowed them to be shared > between instances of the program and even locked in swap with the > sticky bit). A 411 (on hardware that supported it) split the code > and data segments into separate segments. You couldn’t even access > the code as data on the user side (thwarting the nargs function). > > The kernel ran mostly mapped to physical address. However, the user > structure of the current running process was kept in the high segment. > > When we went to Vax, pretty much the same idea was kept (programs > started at location zero and grew up). Some moron decided not only > to start at zero, but put a 0 at location 0 which led to lots of > latent bugs. Later when we got the Gould SELs in we had page zero > unmapped to catch null pointer access, but some programs we didn’t > have source to (notably Oracle) still expected to access *0 with > impunity, so we added a flag we could poke into the header called > “braindead vax compatibility mode” that mapped a zero at zero for > these programs. > > Things got even stranger when we ported to the HEP which had four > kinds of memory > > From tuhs at tuhs.org Tue Jan 20 10:05:34 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 19 Jan 2026 17:05:34 -0700 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: On Mon, Jan 19, 2026 at 12:45 PM ron minnich via TUHS wrote: > I was trying to remember how virtual address space evolved in Unix. > > When I joined the game in v6 days, processes had virtual 0->0xffff, with > the potential for split I/D IIRC, getting you that bit of extra space. The > kernel also had virtual 0->0xffff, also with split I/D. The kernel > accessed user data with mov/load from previous address space instructions. > But also on the 11, trap vectors chewed up a chunk of low physical memory, > and the diode ROM took out some chunk of high physical. The bootstrap you > set from the front panel started with many 1's. > > Later, when we had bigger address spaces on 32- bit systems, page 0 was > made unavailable in users address space to catch NULL pointers. Did that > happen on the VAX at some point, or later? > 4.2BSD on the Vax dereferencing 0 would seg fault. I'm not sure when this started. I am sure that System V or 32V on the Vax dereferencing 0 gave 0. There were many USENET threads about this in the mid 80s. I have first hand experience with 4.2BSD, but not the others. > Later we got the "kernel is high virtual with bit 31 set" -- when did that > first happen? > At some point, the conventions solidify, in the sense that kernels have > high order bits all 1s, and user has page 0x200000 and up; and user mode > does not get any virtual address with high order bit set. My rough memory > is that this convention became most common in the 90s. > I think that's a 32-bit thing as well. Part of it was driven by architecture specific concerns. BSD has linked its kernels at 0xc0000000 since I think 4BSD (I didn't check). The space between 0x80000000 and 0xbfffffff sometimes was kernel, sometimes user depending on the architecture and kernel implementation. FreeBSD does 4G/4G for 32-bit kernels for PowerPC and i386 (though it used to have a 3G/1G split for i386). 32-bit arm, though, is still just 3G/1G for user/kernel split. IIRC, there were some that had a 2G/2G split, but they escape me at the moment (which is the classic 'high bit is kernel). 64-bit architectures make it super easy to have lots of upper bits reserved for this or that, and is beyond the scope of this post. > So, for the pre-mmu Unix, what addresses did processes get, as opposed to > the kernel? Did the kernel get loaded to, and run from, high physical? Did > processes get memory "above trap vectors" and below the kernel? > 16-bit Venix loaded the programs at CS:0/DS:0 but CS and DS specified segments that were well above the hardware interrupt vectors at the bottom and the ROM reset vectors at the top. 16-bit Venix expected programs not to be naughty and set their own DS/ES, but many did to ill effect (since the first trap would set them back on return). > For the era of MMUs, I kmow the data general 32-bit systems put user memory > in "high virtual", which turned out to be really painful, as so many Unix > programs used address 0 (unknown to their authors!). What other Unix > systems used a layout where the kernel was in low virtual? > I've not seen any, but that doesn't mean they don't exist. Warner > I'm not even sure where to find these answers, so apologies in advance for > the questions. > From tuhs at tuhs.org Tue Jan 20 10:48:27 2026 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Mon, 19 Jan 2026 16:48:27 -0800 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: <9b5e912e-bdae-4a4f-846f-9507c64b5e31@oracle.com> On 1/19/26 15:10, Luther Johnson via TUHS wrote: > I once found an old version of RCS that expected *0 = 0, and I think many other > programs did as well. I'm not sure which versions of Unix did or still do this > any more, but I believe many had the first page in virtual address space for > user program processes, mapped to a read-only page of zeroes, to support this. > If I'm remembering that wrong, I'm interested as the other posters here are, in > the details of which did which sorts of things. Deep in the SunOS SCCS archives, the initial checkin of the string(3) man page, labeled as: D 1.1 83/08/30 15:57:14 wnj 1 0 00103/00000/00000 date and time created 83/08/30 15:57:14 by wnj contains this warning in the "BUGS" section: On the Sun processor (and on some other machines), you can NOT use a zero pointer to indicate a null string. A zero pointer is an error and results in an abort of the program. If you wish to indicate a null string, you must have a pointer that points to an explicit null string. On PDP-11's and VAX'en, a source pointer of zero (0) can generally be used to indicate a null string. Programmers using NULL to represent an empty string should be aware of this portability issue. This warning was apparently not sufficient, since in 1994, Bill Shannon added the "0 at 0.so.1" object to Solaris, which you could use with LD_PRELOAD to mmap a page from /dev/zero to the page at address 0, as described in the ld.so.1(1) man page: The user compatibility library /usr/lib/0 at 0.so.1 provides a mechanism that establishes a value of 0 at location 0. Some applications exist that erroneously assume a null character pointer should be treated the same as a pointer to a null string. A segmentation violation occurs in these applications when a null character pointer is accessed. If this library is added to such an application at runtime using LD_PRELOAD, the library provides an environment that is sympathetic to this errant behavior. However, the user compatibility library is intended neither to enable the generation of such applications, nor to endorse this par- ticular programming practice. In many cases, the presence of /usr/lib/0 at 0.so.1 is benign, and it can be preloaded into programs that do not require it. However, there are exceptions. Some applications, such as the JVM (Java Virtual Machine), require that a segmentation violation be generated from a null pointer access. Applications such as the JVM should not preload /usr/lib/0 at 0.so. There are more lines of comments than code in the source for it: https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/sgs/0%400/common/0%400.c -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From tuhs at tuhs.org Tue Jan 20 12:22:04 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 19 Jan 2026 21:22:04 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: <20260120022205.112F6F1FEE63@ary.qy> It appears that ron minnich via TUHS said: >I was trying to remember how virtual address space evolved in Unix. > >When I joined the game in v6 days, processes had virtual 0->0xffff, with >the potential for split I/D IIRC, getting you that bit of extra space. The >kernel also had virtual 0->0xffff, also with split I/D. The kernel > accessed user data with mov/load from previous address space instructions. >But also on the 11, trap vectors chewed up a chunk of low physical memory, >and the diode ROM took out some chunk of high physical. The bootstrap you >set from the front panel started with many 1's. > >Later, when we had bigger address spaces on 32- bit systems, page 0 was >made unavailable in users address space to catch NULL pointers. Did that >happen on the VAX at some point, or later? Someone said in 4.2BSD which seems right. I fixed my share of code that assumed that *0 == 0 >Later we got the "kernel is high virtual with bit 31 set" -- when did that >first happen? That's how VAX addressing worked. User programs were in the low half of the address space, the kernel in the high half. From tuhs at tuhs.org Tue Jan 20 12:47:25 2026 From: tuhs at tuhs.org (George Michaelson via TUHS) Date: Tue, 20 Jan 2026 12:47:25 +1000 Subject: [TUHS] Craig Partridge on BBN vs BSD TCP/IP Message-ID: Craig wrote this to the IETF list, when people started talking some TCP/IP history. Since it's about the DARPA funded work at Berkeley, and the prior BBN implementation and how people (Craig certainly!) felt about it, I thought it might be interesting for folk here. It's opinionated, but there's nothing wrong with opine IMO https://mailarchive.ietf.org/arch/msg/ietf/rbWOYPjlCs2HwT4x66Hsuu7bCpI -G From tuhs at tuhs.org Tue Jan 20 15:40:12 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Tue, 20 Jan 2026 05:40:12 +0000 Subject: [TUHS] Yacc binary on 4th edition tape In-Reply-To: (Jonathan Gray via TUHS's message of "Mon, 19 Jan 2026 19:38:56 +1100") References: <792DD77D-8BEB-4CC9-AFE6-F92C2F73BB1F@planet.nl> Message-ID: <7wpl74hmf7.fsf@junk.nocrew.org> Jonathan Gray via TUHS writes: >> > - 1971: first version of yacc created in B > "yacc was written in 1972" Alan Snyder was at Bell labs in this time period, and brought C and yacc back to MIT. The input file to his yacc looks rather archanic, perhaps influenced by the B yacc? I asked Johnson about it, but he didn't recognize it. Here's an example, the grammar for Snyder's C compiler. https://github.com/PDP-10/its/blob/master/src/c/c.grammr From tuhs at tuhs.org Tue Jan 20 22:18:00 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Tue, 20 Jan 2026 07:18:00 -0500 (EST) Subject: [TUHS] Craig Partridge on BBN vs BSD TCP/IP Message-ID: <20260120121800.5693E18C077@mercury.lcs.mit.edu> > From: George Michaelson > Craig wrote this to the IETF list > From: Craig Partridge >> The UNIX implementation was done at BBN, if I remember correctly, by >> Jack Haverty. There were _two_ PDP-11 UNIX implementations at BBN. The first, in MACRO-11, by Jack Haverty, was a port of the one done at SRI by Jim Mathis. The second, in C, was done by Mike Wingfield. I don't know if this one influenced the VAX Unix one by Gurwitz. See: https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6 for its source, and: https://www.rfc-editor.org/ien/scanned/ien98.pdf for more about it. Noel From tuhs at tuhs.org Wed Jan 21 01:45:15 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Tue, 20 Jan 2026 10:45:15 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: <20260120022205.112F6F1FEE63@ary.qy> References: <20260120022205.112F6F1FEE63@ary.qy> Message-ID: On Mon, Jan 19, 2026 at 9:22 PM John Levine via TUHS wrote: > > >Later we got the "kernel is high virtual with bit 31 set" -- when did that > >first happen? > > That's how VAX addressing worked. User programs were in the low half > of the address space, the kernel in the high half. > It has nothing to do with how the VAX implements virtual addressing per se. It's more to do with the way that the various a.out formats for program images (OMAGIC, NMAGIC, ZMAGIC) all assume that program addressing starts at 0. It offers the greatest convenience and flexibility if the parts of kernel address space that must be mapped into user process address space are at the high end of the address space, well out of the way of user code and data. VAX/VMS had the convention that all addresses with bit 31 on were reserved to the operating system. And the first page of process address space (0-512K) was both read- and write-protected so that any attempt to use a null pointer or small integer as an address generated an exception. IMO one of the best design decisions ever done in an ABI. It caught countless program errors. Unix seems to have followed VAX/VMS's lead on address space layout on the VAX. Where did Unix put the process stack on VAX? In VAX/VMS it was at the top of the user VA space and grew downward. Contrariwise the top of heap memory (the break in Unix-speak) started just after the statically allocated part of the program image (including any mapped shared images) and grew upwards. -Paul W. From tuhs at tuhs.org Wed Jan 21 02:49:25 2026 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Tue, 20 Jan 2026 11:49:25 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: On Mon, Jan 19, 2026 at 7:05 PM Warner Losh via TUHS wrote: > 4.2BSD on the Vax dereferencing 0 would seg fault. I'm not sure when this > started. I am sure that System V or 32V on the Vax dereferencing 0 gave > 0. Are you sure? My memory is the opposite. For example, https://www.tuhs.org/Usenet/comp.bugs.4bsd/1989-July/003016.html From tuhs at tuhs.org Wed Jan 21 04:18:00 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 20 Jan 2026 18:18:00 +0000 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: Indeed, 4BSD had a zero located at location zero. Amusingly the PDP-11 had code down there. You knew you were dereferencing zero when “p&P6” showed up in your output. This is what was left printable in the first few instructions of crt0.o (a setd instruction followed by others). ------ Original Message ------ >From "Rich Salz via TUHS" To "Warner Losh" Cc "The Eunuchs Hysterical Society" Date 1/20/2026 11:49:25 AM Subject [TUHS] Re: history of virtual address space >On Mon, Jan 19, 2026 at 7:05 PM Warner Losh via TUHS wrote: > >> 4.2BSD on the Vax dereferencing 0 would seg fault. I'm not sure when this >> started. I am sure that System V or 32V on the Vax dereferencing 0 gave >> 0. > > >Are you sure? My memory is the opposite. For example, >https://www.tuhs.org/Usenet/comp.bugs.4bsd/1989-July/003016.html From tuhs at tuhs.org Wed Jan 21 04:24:35 2026 From: tuhs at tuhs.org (John R Levine via TUHS) Date: 20 Jan 2026 13:24:35 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: References: <20260120022205.112F6F1FEE63@ary.qy> Message-ID: > On Mon, Jan 19, 2026 at 9:22 PM John Levine via TUHS wrote: > >> >>> Later we got the "kernel is high virtual with bit 31 set" -- when did that >>> first happen? >> >> That's how VAX addressing worked. User programs were in the low half >> of the address space, the kernel in the high half. >> > > It has nothing to do with how the VAX implements virtual addressing per > se. ... The 1981 VAX Architecture Handbook that I have in my hand disagrees with you. The Memory Management chapter says that the top half of the address space is the System (S) while the bottom half is Process. Process is further divided into P0 which grows up from 0 and P1 which grows down from the middle. There is one S page table which is in real memory. The P0 and P1 page tables are in S address space, giving the effect of two-level page tables. Each page table is logically contiguous, with a base and length register for each. The a.out program layout is the only one that makes sense on a Vax, code starts at zero, stack grows down from 2GB. R's, John From tuhs at tuhs.org Wed Jan 21 04:59:56 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Tue, 20 Jan 2026 13:59:56 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: References: <20260120022205.112F6F1FEE63@ary.qy> Message-ID: On Tue, Jan 20, 2026 at 1:24 PM John R Levine wrote: > > On Mon, Jan 19, 2026 at 9:22 PM John Levine via TUHS > wrote: > > > >> > >>> Later we got the "kernel is high virtual with bit 31 set" -- when did > that > >>> first happen? > >> > >> That's how VAX addressing worked. User programs were in the low half > >> of the address space, the kernel in the high half. > >> > > > > It has nothing to do with how the VAX implements virtual addressing per > > se. ... > > The 1981 VAX Architecture Handbook that I have in my hand disagrees with > you. The Memory Management chapter says that the top half of the address > space is the System (S) while the bottom half is Process. Process is > further divided into P0 which grows up from 0 and P1 which grows down from > the middle. There is one S page table which is in real memory. The P0 > and P1 page tables are in S address space, giving the effect of two-level > page tables. Each page table is logically contiguous, with a base and > length register for each. > > The a.out program layout is the only one that makes sense on a Vax, code > starts at zero, stack grows down from 2GB. > > I am very familiar with the 1981 VAX Architecture Handbook. It is a somewhat misleading document in that it is describing both how the VAX hardware works (this is what I would call the "VAX Architecture") but also the Application Binary Interface (ABI) of the VAX/VMS operating system. Remember that at the time DEC was adopting a "one architecture, one operating system" approach on VAX. They were trying to intimately link VAX (the hardware architecture) and VMS (the operating system) in the minds of both DEC's own engineers and their customers. The Memory Management chapter is describing the memory layout of a VAX/VMS process. If you look at the hardware architecture side of things, you will see that there is absolutely no requirement or constraint at the hardware level to have all of the virtual addresses with the high bit on be reserved to the OS and those with the high bit off to user space. Each page table entry has its own protection bits that describe the read and write permissions for each execution mode (user/supervisor/executive/kernel). Bottom line is, back in the early days of VAX, when DEC referred to "VAX Architecture" they meant both the hardware architecture of VAX and the OS architecture of VMS. Contrast this with "PDP-11 Architecture", which meant only the hardware design, not the veritable zoo of operating systems that ran on the PDP-11, each of which had its own peculiarities regarding memory addressing. One could have, if one wanted, done the opposite and put user address space in the address range with the high bit on and the kernel address space in the low part of the address space. It would be fully conformant with the VAX page table layout and supported by all then-extant (11/780/750/730) and future VAXen. Unix chose to follow the VMS design (as documented in the VAX Architecture Manual) pretty much because there was no reason not to. -Paul W. From tuhs at tuhs.org Wed Jan 21 05:03:50 2026 From: tuhs at tuhs.org (John R Levine via TUHS) Date: 20 Jan 2026 14:03:50 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: References: <20260120022205.112F6F1FEE63@ary.qy> Message-ID: On Tue, 20 Jan 2026, Paul Winalski wrote: > The Memory Management chapter is describing the memory layout of a VAX/VMS > process. If you look at the hardware architecture side of things, you will > see that there is absolutely no requirement or constraint at the hardware > level to have all of the virtual addresses with the high bit on be reserved > to the OS and those with the high bit off to user space. Each page table > entry has its own protection bits that describe the read and write > permissions for each execution mode (user/supervisor/executive/kernel). Did you miss the bit about the S page tables being in real memory and the P0 and P1 in S memory, with P1 growing down from 2GB? Really, the hardware dictates the layout. You might want to find a copy of the handbook and refresh your memory. > One could have, if one wanted, done the opposite and put user address space > in the address range with the high bit on and the kernel address space in > the low part of the address space. It would be fully conformant with the > VAX page table layout and supported by all then-extant (11/780/750/730) and > future VAXen. Nope. Please reead the handbook. Regards, John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From tuhs at tuhs.org Wed Jan 21 05:38:00 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Tue, 20 Jan 2026 12:38:00 -0700 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: On Tue, Jan 20, 2026, 9:49 AM Rich Salz wrote: > > > On Mon, Jan 19, 2026 at 7:05 PM Warner Losh via TUHS > wrote: > >> 4.2BSD on the Vax dereferencing 0 would seg fault. I'm not sure when this >> started. I am sure that System V or 32V on the Vax dereferencing 0 gave >> 0. > > > Are you sure? My memory is the opposite. For example, > https://www.tuhs.org/Usenet/comp.bugs.4bsd/1989-July/003016.html > Maybe it was a local hack. I know for sure that the vax assembler i wrote definitely core dump when i did *NULL... it may have been 4.3 by then... I also recall a prof or TA saying that 4.1BSD burned a lot of time on infinite loops that students wrote, but now they are core dumps... But I've not looked at the 4.3 sources to see if that's unmapped. Warner > > From tuhs at tuhs.org Wed Jan 21 05:47:42 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Tue, 20 Jan 2026 14:47:42 -0500 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: References: Message-ID: The discussion of the history of virtual addressing in Unix called to my mind a related question: The VAX has four protection modes, from lowest to highest in privilege: user, supervisor, executive, kernel. Access to certain instructions and hardware data structures can only be done from kernel mode. User mode is of course intended for use by non-privileged code and data. The VAX/VMS Digital Command Language (DCL) command interpreter ran in supervisor mode. Record Management Services (RMS, the primary way to access disk files) ran in executive mode. The kernel, device drivers, hardware interrupt handlers, etc. ran in kernel mode. Obviously Unix user-mode process code and data ran in user mode. Likewise the parts of the kernel that had to access privileged bits of the hardware (such as device drivers) must have run in kernel mode. My question is, did Unix make any use of either supervisor or executive mode on the VAX? -Paul W. From tuhs at tuhs.org Wed Jan 21 05:58:47 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Tue, 20 Jan 2026 14:58:47 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: References: <20260120022205.112F6F1FEE63@ary.qy> Message-ID: <202601201958.60KJwllu043391@ultimate.com> The "feature" of having user and system use non-overlapping virtual address ranges makes reading user data (eg system call arguments) easy (*) The VAX reserving a full half of the address space for the system software has always struck me of typical of the mindset of kernel/monitor developers thru the ages: Cycles expended outside of the system state (ie; by users) are wasted(**)!! (*) PDP-10's with paging systems all implemented special a "previous context" flavor of the XCT (execute) instruction for moving data between system and user spaces (systems with more physical memory than the full/original 256K word 18-bit virtual address space were common from the start. (**) I first noticed it at DEC in the 80's; TOPS-20 monitor developers hating on EMACS users wasting time by context switching on each keystroke. From tuhs at tuhs.org Wed Jan 21 06:05:59 2026 From: tuhs at tuhs.org (Paul Winalski via TUHS) Date: Tue, 20 Jan 2026 15:05:59 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: References: <20260120022205.112F6F1FEE63@ary.qy> Message-ID: On Tue, Jan 20, 2026 at 10:45 AM Paul Winalski wrote: > > It has nothing to do with how the VAX implements virtual addressing per > se. It's more to do with the way that the various a.out formats for > program images (OMAGIC, NMAGIC, ZMAGIC) all assume that program addressing > starts at 0. It offers the greatest convenience and flexibility if the > parts of kernel address space that must be mapped into user process address > space are at the high end of the address space, well out of the way of user > code and data. > > I found and downloaded a copy of the 1981 VAX Architecture Handbook and it turns out I was wrong about this. The page table design for VAX defines three ranges of virtual addresses: System (S): bit 31 of virtual address on Program 0 (P0): bits 31 and 30 of virtual address off Program 1 (P1): bit 31 of virtual address off, bit 30 on Each page table has a pair of hardware registers defining the base and length of the page table (SBR/SLR, P0BR/P0LR, P1BR, P1LR). The SBR address is a physical address. The P0BR and P1BR addresses are virtual addresses in system (bit 31 on) space. This design facilitates a virtual address layout where there is a single system address range occupying high virtual memory and per-process P0 and P1 regions. P1 is intended to implement a stack that grows downwards from virtual address 0x7fffffff. P0 is intended to implement code and heap space growing upwards from 0x00000000. VAX/VMS set the protection on the first page of memory to allow neither read nor write access to any of the four protection modes, so that any attempt to use small integers in the range 0-511 (decimal) caused a seg fault. This caught countless programming errors. So the virtual address layout of early Unix on the VAX was indeed dictated by the page table mechanism of the VAX hardware. Thanks to John Levine for correcting me on this. -Paul W. From tuhs at tuhs.org Wed Jan 21 06:59:29 2026 From: tuhs at tuhs.org (brantley coile via TUHS) Date: Tue, 20 Jan 2026 15:59:29 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: <202601201958.60KJwllu043391@ultimate.com> References: <20260120022205.112F6F1FEE63@ary.qy> <202601201958.60KJwllu043391@ultimate.com> Message-ID: I don't know if system designers thought that every cycle executed outside of system state was wasted or not, but the idea of four billion bytes of RAM begin installed in the system seemed like a far away fantasy in 1978. The most one could ever cram into a 780 was 128 MB. I was working on a machine with 256 KB and it seemed quite large. The big machines (IBM 370/158 and CDC Cyber 70/74) only had 4 MB and 128 KB. (The 128KB were 60 bits, I grant you.) Again, no opinion on designers attitudes towards pesky users. Brantley > On Jan 20, 2026, at 2:58 PM, Phil Budne via TUHS wrote: > > The "feature" of having user and system use non-overlapping virtual > address ranges makes reading user data (eg system call arguments) easy (*) > > The VAX reserving a full half of the address space for the system > software has always struck me of typical of the mindset of > kernel/monitor developers thru the ages: Cycles expended outside of > the system state (ie; by users) are wasted(**)!! > > (*) PDP-10's with paging systems all implemented special a "previous > context" flavor of the XCT (execute) instruction for moving data > between system and user spaces (systems with more physical memory than > the full/original 256K word 18-bit virtual address space were common > from the start. > > (**) I first noticed it at DEC in the 80's; TOPS-20 monitor developers > hating on EMACS users wasting time by context switching on each > keystroke. From tuhs at tuhs.org Wed Jan 21 07:51:00 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Tue, 20 Jan 2026 14:51:00 -0700 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: Looking at 4.2BSD sources, I don't see any offset for address 0. a.out makes it kinda hard to unmap page 0. The compiler would have to put a start address into the a.out header, and the 4 binaries I checked had an a_entry of 0.. But it looks like only the stand alone programs use a_entry... But that's hidden as this inside setregs() in kern_exec.c: u.u_ar0[PC] = u.u_exdata.ux_entloc+2; and that type puns to a.out's a_entry, so that's going to jump to 0. 4.3BSD spells it a little differently: setregs(exdata.ex_exec.a_entry); but has the same a_entry == 0. setregs moved to vax/machdep.c where it adds 2. So maybe my memory is bad, maybe we had a local hack. I acn't find out for sure, but stock 4.3BSD/vax necessarily maps page 0. Warner On Tue, Jan 20, 2026 at 12:38 PM Warner Losh wrote: > > > On Tue, Jan 20, 2026, 9:49 AM Rich Salz wrote: > >> >> >> On Mon, Jan 19, 2026 at 7:05 PM Warner Losh via TUHS >> wrote: >> >>> 4.2BSD on the Vax dereferencing 0 would seg fault. I'm not sure when this >>> started. I am sure that System V or 32V on the Vax dereferencing 0 gave >>> 0. >> >> >> Are you sure? My memory is the opposite. For example, >> https://www.tuhs.org/Usenet/comp.bugs.4bsd/1989-July/003016.html >> > > > Maybe it was a local hack. I know for sure that the vax assembler i wrote > definitely core dump when i did *NULL... it may have been 4.3 by then... I > also recall a prof or TA saying that 4.1BSD burned a lot of time on > infinite loops that students wrote, but now they are core dumps... But I've > not looked at the 4.3 sources to see if that's unmapped. > > Warner > >> >> From tuhs at tuhs.org Wed Jan 21 08:07:21 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Tue, 20 Jan 2026 15:07:21 -0700 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: References: Message-ID: On Tue, Jan 20, 2026 at 12:48 PM Paul Winalski via TUHS wrote: > The discussion of the history of virtual addressing in Unix called to my > mind a related question: > > The VAX has four protection modes, from lowest to highest in privilege: > user, supervisor, executive, kernel. Access to certain instructions and > hardware data structures can only be done from kernel mode. User mode is > of course intended for use by non-privileged code and data. The VAX/VMS > Digital Command Language (DCL) command interpreter ran in supervisor mode. > Record Management Services (RMS, the primary way to access disk files) ran > in executive mode. The kernel, device drivers, hardware interrupt > handlers, etc. ran in kernel mode. > > Obviously Unix user-mode process code and data ran in user mode. Likewise > the parts of the kernel that had to access privileged bits of the hardware > (such as device drivers) must have run in kernel mode. > > My question is, did Unix make any use of either supervisor or executive > mode on the VAX? > My 1987 OS class said it only used user and kernel mode. Looking at the 4.3BSD kernel, it either sets both priv bits, or clears both the bits. I don't see where it would be using supervisor or executive mode, but this was a super fast grep for PSL manipulation Warner From tuhs at tuhs.org Wed Jan 21 08:37:45 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 20 Jan 2026 22:37:45 +0000 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: There was a start address in the a.out header. This dates back to the V6 days (or perhaps earlier). The header was on the PDP-11: Magic number Text size Data Size BSS size Symbol Table Syze ENTRY LOCATION and the last two 16 bit values were unused. When 4BSD came to the vax, the new header was pretty much the same only with longs instead of shorts. ------ Original Message ------ >From "Warner Losh via TUHS" To "Rich Salz" Cc "The Eunuchs Hysterical Society" Date 1/20/2026 4:51:00 PM Subject [TUHS] Re: history of virtual address space >Looking at 4.2BSD sources, I don't see any offset for address 0. a.out >makes it kinda hard to unmap page 0. The compiler would have to put a start >address into the a.out header, and the 4 binaries I checked had an a_entry >of 0.. But it looks like only the stand alone programs use a_entry... But >that's hidden as this inside setregs() in kern_exec.c: > u.u_ar0[PC] = u.u_exdata.ux_entloc+2; >and that type puns to a.out's a_entry, so that's going to jump to 0. > >4.3BSD spells it a little differently: > setregs(exdata.ex_exec.a_entry); >but has the same a_entry == 0. setregs moved to vax/machdep.c where it adds >2. > >So maybe my memory is bad, maybe we had a local hack. I acn't find out for >sure, but stock 4.3BSD/vax necessarily maps page 0. > >Warner > >On Tue, Jan 20, 2026 at 12:38 PM Warner Losh wrote: > >> >> >> On Tue, Jan 20, 2026, 9:49 AM Rich Salz wrote: >> >>> >>> >>> On Mon, Jan 19, 2026 at 7:05 PM Warner Losh via TUHS >>> wrote: >>> >>>> 4.2BSD on the Vax dereferencing 0 would seg fault. I'm not sure when this >>>> started. I am sure that System V or 32V on the Vax dereferencing 0 gave >>>> 0. >>> >>> >>> Are you sure? My memory is the opposite. For example, >>> https://www.tuhs.org/Usenet/comp.bugs.4bsd/1989-July/003016.html >>> >> >> >> Maybe it was a local hack. I know for sure that the vax assembler i wrote >> definitely core dump when i did *NULL... it may have been 4.3 by then... I >> also recall a prof or TA saying that 4.1BSD burned a lot of time on >> infinite loops that students wrote, but now they are core dumps... But I've >> not looked at the 4.3 sources to see if that's unmapped. >> >> Warner >> >>> >>> From tuhs at tuhs.org Wed Jan 21 09:07:15 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 20 Jan 2026 18:07:15 -0500 Subject: [TUHS] history of virtual address space In-Reply-To: References: Message-ID: below On Mon, Jan 19, 2026 at 7:05 PM Warner Losh via TUHS wrote: > > 4.2BSD on the Vax dereferencing 0 would seg fault. As the default was an optional setup that allowed the previous(4.1) behaviour. > I'm not sure when this started. 4.2BSD was the first time it was the default. > I am sure that System V or 32V on the Vax dereferencing 0 gave 0. Yes, the original Vax kernel from BSD inherited that behaviour from 32/V - more in a minute. > There were many USENET threads about this in the mid 80s. > Exactly. IMO, the worst offender was the V7 Bourne shell implementation; the way it managed its heap depended on it. By that time, ports of Unix were available on other ISPs besides the PDP-11. And many people started to trip over the problem. At Berkeley, there was much debate, and everyone agreed it was a sin. In fact its #2 in Henry's famous list of the ten commandments: Thou shalt not follow the NULL pointer , for chaos and madness await thee at its end. The feeling was if we protected page zero, then you could get a page fault, and we could start fixing utilities. It was interesting when you found one (I remember stumbling it one in the Rand MH mail system). But the problem was that, by this time frame, a large body of C code had begun to emerge that people found useful, but had this hidden flaw. So, with one of the early pre-4.2 releases (4.1 A/B/C), it could be configured as an option. I ran the CAD Vaxen with it turned on as soon as we had a system that could support it. By the time of the full release, 4.2BSD had protected page 0. From tuhs at tuhs.org Wed Jan 21 09:10:47 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 20 Jan 2026 18:10:47 -0500 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: References: Message-ID: Paul for the Vax, 32V, the Vax based BSD's, Ultrix32 all used kernel and user. The original PDP-11's worked that way also. But with 2.11BSD, the networking code was moved into the supervisor (11's only have 3 possible modes). This was done for address space reasons. It's a nice piece of work. On Tue, Jan 20, 2026 at 2:48 PM Paul Winalski via TUHS wrote: > The discussion of the history of virtual addressing in Unix called to my > mind a related question: > > The VAX has four protection modes, from lowest to highest in privilege: > user, supervisor, executive, kernel. Access to certain instructions and > hardware data structures can only be done from kernel mode. User mode is > of course intended for use by non-privileged code and data. The VAX/VMS > Digital Command Language (DCL) command interpreter ran in supervisor mode. > Record Management Services (RMS, the primary way to access disk files) ran > in executive mode. The kernel, device drivers, hardware interrupt > handlers, etc. ran in kernel mode. > > Obviously Unix user-mode process code and data ran in user mode. Likewise > the parts of the kernel that had to access privileged bits of the hardware > (such as device drivers) must have run in kernel mode. > > My question is, did Unix make any use of either supervisor or executive > mode on the VAX? > > -Paul W. > From tuhs at tuhs.org Wed Jan 21 12:08:09 2026 From: tuhs at tuhs.org (Erik E. Fair via TUHS) Date: Tue, 20 Jan 2026 18:08:09 -0800 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: References: Message-ID: <17274.1768961289@cesium.clock.org> With regard to systems which didn't have address 0 in their user process address space (and thus dereferencing address 0 resulted in SIGSEGV), the first Unix (7th Edition) on a mc68000 was that way: the Dual Systems 83/80 S-100 (IEEE-696) bus system in November 1981. Jeff Schriebman did the port, and founded UniSoft Systems not very far away from Dual in West Berkeley. Dual was UniSoft's first customer. Others: Apple Computer (for the Lisa - the parallel port based "Profile" hard drive was a horror), and a host of (Intel) MultiBus-based systems: Fortune, Pixel, Plexus, WiCat, CoData ... Plop a 5 MHz mc68000 alas without an mc68451 (or other) MMU on an S-100 card, and how to protect the kernel? Split the 24-bit address space in half: bottom (from 0) for the kernel, top half (0x800000 and above) for user processes, and simple logic to test processor mode vs high (most significant) bit in any memory reference: any access of kernel address space (address msb = 0) while the processor is in user mode generates a trap or interrupt, such that the kernel can deliver SIGSEGV to the offending process. Base system configuration: 128KB RAM, 64KB for kernel, 64KB for user, literally in two S-100 DRAM cards with appropriate base addresses set in their DIP switches. Naturally, all user software that dereferenced address 0 failed, and there was a lot of that to be cleaned up. Also, some customers told us that our hardware was wrong (nope - logic error on the part of the programmers who assumed address 0 was accessible, i.e., (*NULL); we didn't sell you a DEC PDP-11 which started this whole mess). Also, yeah, Bourne shell's ... interesting ... notions of memory management: SEG fault? Catch it, and sbrk(2)! Doesn't work on the mc68000 because it didn't keep enough state for restarting faulted instructions unlike the DEC PDP-11 (Clem, do you want to chime in here to describe MassComp's extravagant solution to that?). Asa Romberger recounted the tale of refactoring Bourne shell for mc68000 to me while I was working for Dual and visiting UniSoft relatively frequently. The mc68010 fixed that incomplete fault state bug, and made demand-paged virtual memory possible for mc68k-family-based systems. Virtually addressed memory came with the mc68451 MMU (but that had other awful problems which is probably so many mc68k box system manufacturers rolled their own MMUs). Before that, IIRC, Dual's Unix was swap-based: had to run each user process loaded from 0x800000 ... so put the ones you're not running in the swap partition of the system disk. Slow. It was even possible to run Unix from 8-inch floppies, which was even slower, but I knew a guy who did for a while. I still have a lot of hate for USL because I spent a year cleaning up their bugs in System III, plus it was missing basically all BSD enhancements for better usability (the worst was not having the BSD tty line discipline, and job control). Dual never fully released it - by the time we were ready, System V was out, and we had to do it all over again. Erik From tuhs at tuhs.org Wed Jan 21 12:19:18 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 21 Jan 2026 02:19:18 +0000 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: <17274.1768961289@cesium.clock.org> References: <17274.1768961289@cesium.clock.org> Message-ID: <5ADKQ6FNxHB8GiV9MYfnsCCq6A_SRkJvp7moYvdNYilrQbg8keOpP46bN2nS-lJ_do3MEoSyQs2q_EWKiOzcVxp9QARyA1lldIwM7gh93MI=@protonmail.com> On Tuesday, January 20th, 2026 at 18:08, Erik E. Fair via TUHS wrote: > With regard to systems which didn't have address 0 in their user process address space (and thus dereferencing address 0 resulted in SIGSEGV), the first Unix (7th Edition) on a mc68000 was that way: the Dual Systems 83/80 S-100 (IEEE-696) bus system in November 1981. > > > Erik Wouldn't all 68k execution at least until VM kicks in avoid the bottom of memory as that is where the exception vectors live? With no standard MMU, I'd assume each 68k implementation had some freedom in setting their VM characteristics relative to whatever MMU folks went with. Vector 0 (long) holds the initial stack pointer and vector 1 holds the initial PC. On non-UNIX 68k systems I've dealt with, this area is fed by ROM. and thus read-only. At most, 0 accesses would give you the high byte of the initial SP, likely either a 0 or 255 due to sign extension of the 24-bit vector. Presumably VM layouts put this somewhere else, if mapped at all, and reassigned 0 to start at some hunk of RAM when VM was turned on in common 68k kernels? This does raise the question in my mind of which MMU the ATTIS/USL 68k port expected, how they made that choice, and what implications that had for 68k boxen that wanted to license System V but had a MMU that wasn't supported (if you'd even get that far down the R&D pipeline without verifying your MMU is supported)? - Matt G. From tuhs at tuhs.org Wed Jan 21 12:48:48 2026 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Tue, 20 Jan 2026 18:48:48 -0800 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: <17274.1768961289@cesium.clock.org> References: <17274.1768961289@cesium.clock.org> Message-ID: <2A936782-B478-4561-88DA-05893B0E4F8A@iitbombay.org> Fortune, a 68K based system, had a custom external MMU with 4 segments, built using MSI TTL chips. Recall that the orig 68K supported up to 16MB of memory (24 bit ptrs): purpose base limit text 0x000000 base+size data 0x400000 base+size extra 0xbfffff base-size (i.e. segment could grow downward) stack 0xffffff base-size IIRC the kernel was loaded a 0x0 physical address (or may be the ROM was there -- wherever the 68k started after being brought out from a reset state). Upto 4 256KB memory cards could be plugged in. To context switch you had to reload the segment registers with the physical addr and limits of the new process. copyin/copyout of syscall args were asm functions to deal with these segments. The compiler generated function entry prolog code to access end of the needed local frame. If this was past the stack limit, the stack would be grown in the trap handler. IIRC this was one instruction that could be restarted safely? The swap was needed only when the sum total of process space exceeded physmem - kernel space (256K to 1MB max on the original system). Another neat hack: IO driver for an IO device was stored on the relevant IO card itself. Each IO slot was at diff. address and the system queried for the presence of a card. If one was found it had to follow the IO API we had defined to provide device name, what kind of device etc.etc. > On Jan 20, 2026, at 6:08 PM, Erik E. Fair via TUHS wrote: > > With regard to systems which didn't have address 0 in their user process address space (and thus dereferencing address 0 resulted in SIGSEGV), the first Unix (7th Edition) on a mc68000 was that way: the Dual Systems 83/80 S-100 (IEEE-696) bus system in November 1981. > > Jeff Schriebman did the port, and founded UniSoft Systems not very far away from Dual in West Berkeley. Dual was UniSoft's first customer. Others: Apple Computer (for the Lisa - the parallel port based "Profile" hard drive was a horror), and a host of (Intel) MultiBus-based systems: Fortune, Pixel, Plexus, WiCat, CoData ... > > Plop a 5 MHz mc68000 alas without an mc68451 (or other) MMU on an S-100 card, and how to protect the kernel? Split the 24-bit address space in half: bottom (from 0) for the kernel, top half (0x800000 and above) for user processes, and simple logic to test processor mode vs high (most significant) bit in any memory reference: any access of kernel address space (address msb 0) while the processor is in user mode generates a trap or interrupt, such that the kernel can deliver SIGSEGV to the offending process. Base system configuration: 128KB RAM, 64KB for kernel, 64KB for user, literally in two S-100 DRAM cards with appropriate base addresses set in their DIP switches. > > Naturally, all user software that dereferenced address 0 failed, and there was a lot of that to be cleaned up. Also, some customers told us that our hardware was wrong (nope - logic error on the part of the programmers who assumed address 0 was accessible, i.e., (*NULL); we didn't sell you a DEC PDP-11 which started this whole mess). > > Also, yeah, Bourne shell's ... interesting ... notions of memory management: SEG fault? Catch it, and sbrk(2)! Doesn't work on the mc68000 because it didn't keep enough state for restarting faulted instructions unlike the DEC PDP-11 (Clem, do you want to chime in here to describe MassComp's extravagant solution to that?). Asa Romberger recounted the tale of refactoring Bourne shell for mc68000 to me while I was working for Dual and visiting UniSoft relatively frequently. The mc68010 fixed that incomplete fault state bug, and made demand-paged virtual memory possible for mc68k-family-based systems. > > Virtually addressed memory came with the mc68451 MMU (but that had other awful problems which is probably so many mc68k box system manufacturers rolled their own MMUs). Before that, IIRC, Dual's Unix was swap-based: had to run each user process loaded from 0x800000 ... so put the ones you're not running in the swap partition of the system disk. Slow. It was even possible to run Unix from 8-inch floppies, which was even slower, but I knew a guy who did for a while. > > I still have a lot of hate for USL because I spent a year cleaning up their bugs in System III, plus it was missing basically all BSD enhancements for better usability (the worst was not having the BSD tty line discipline, and job control). Dual never fully released it - by the time we were ready, System V was out, and we had to do it all over again. > > Erik From tuhs at tuhs.org Wed Jan 21 16:57:26 2026 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Wed, 21 Jan 2026 07:57:26 +0100 Subject: [TUHS] Yacc binary on 4th edition tape Message-ID: <425DC8FF-25F3-40E0-B6CA-9C8E3E981F7E@planet.nl> > Alan Snyder was at Bell labs in this time period, and brought C and yacc > back to MIT. The input file to his yacc looks rather archanic, perhaps > influenced by the B yacc? I asked Johnson about it, but he didn't > recognize it. Here's an example, the grammar for Snyder's C compiler. > > https://github.com/PDP-10/its/blob/master/src/c/c.grammr That is an interesting link. It uses some of the syntax that is mentioned as deprecated in the Johnson Yacc paper on your site: This appendix mentions synonyms and features which are supported for historical continuity, but, for various reasons, are not encouraged. 1. Literals may be delimited by double quotes ‘‘"’’ as well as single quotes ‘‘´’’. 2. Literals may be more than one character long. If all the characters are alphabetic, numeric, or _, the type number of the literal is defined, just as if the literal did not have the quotes around it. Otherwise, it is difficult to find the value for such literals. 3. The use of multi-character literals is likely to mislead those unfamiliar with Yacc, since it suggests that Yacc is doing a job which must be actually done by the lexical analyzer. 4. Most places where % is legal, backslash ‘‘\’’ may be used. In particular, \\ is the same as %%, \left the same as %left, etc. There are a number of other synonyms: %< is the same as %left %> is the same as %right %binary and %2 are the same as %nonassoc %0 and %term are the same as %token %= is the same as %prec 5. The curly braces ‘‘{’’ and ‘‘}’’ around an action are optional if the action consists of a single C statement. (They are always required in Ratfor). These old forms are still accepted by Yacc as present in the surviving V6 source files. The Snyder grammer uses backslash instead of percent and also the short forms (i.e. “\>” for “%right”). It does not put “\0” in front of the token definitions, and it does use multi-character literals. When I have time, I will attempt to disassemble/reverse the file “y2.c” from the 1974 binary as well (this has the lexer / parser part of yacc). This should give a view on Yacc grammar in mid-1974. As to the grammar itself, I am a little confused by the single letter tokens ‘l’ through ’s’ which don’t appear used in the grammer, and I’m intrigued by the use of the name “.expression” for a rule to allow empty expressions in the FOR statement: the Eh grammar from Waterloo uses that name as well for this purpose (suggesting a common root). === I was a focused on the optimizer earlier and missed two relevant files from the PWB1 yacc source tree: https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s2/yacc.d/INDEX https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s2/yacc.d/yaccdiffs "The archive file contains information for testing and installing Version 2 of Yacc.” So at the time it was seen as Yacc 1 and Yacc 2, perhaps not surprising considering the material improvement in performance (much smaller tables, much faster parsing). The earlier Johnson papers appear to talk about Yacc 1 and the later versions about Yacc 2. The source in the V6 tree is Yacc 1 and the source in the PWB1 tree is Yacc 2. From tuhs at tuhs.org Wed Jan 21 18:39:29 2026 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Wed, 21 Jan 2026 09:39:29 +0100 Subject: [TUHS] Craig Partridge on BBN vs BSD TCP/IP Message-ID: <0BEC1C8D-17AB-4828-8E66-20ABDA4622DC@planet.nl> > Craig wrote this to the IETF list, when people started talking some TCP/IP > history. Since it's about the DARPA funded work at Berkeley, and the prior > BBN implementation and how people (Craig certainly!) felt about it, I > thought it might be interesting for folk here. > > It's opinionated, but there's nothing wrong with opine IMO > > https://mailarchive.ietf.org/arch/msg/ietf/rbWOYPjlCs2HwT4x66Hsuu7bCpI > > -G About 7 years ago I dived deep into the history of this and Craig was very helpful to locate and retrieve BBN document for that effort. At the time I did start on writing some pages for the TUHS FAQ section, but never quite finished the effort. The draft text is staged here: https://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=early_networking There are also many posts to this list between, say, 2016 and 2020. The competition between the BBN stack and the CSRG stack was emotional and political at the time and this makes it tough to get a clear view on the technical history. Below some of my own conclusions and they are necessarily just that, my own conclusions. - The BBN (and earlier NCP) stack designed to have minimal code interaction with the rest of the kernel. In the late seventies both the network stacks and the unix kernel were developing fast and minimal code interaction made sense. The BBN work continued in this line, also because it was supposed to be reference code for integration in multiple operating systems. CSRG on the other hand was (amongst other things) tasked to develop an API to support (distributed) message passing architectures and to integrate this with the Unix kernel. - The BBN team was targeting Arpanet which used 50kb modems and satellite links. The CSRG team was targeting local area networks, notably early ethernet. Hence, the BBN code focused on reliability over poor connections, the CSRG code focused on speed over more reliable connections. The different contexts lead to different design choices being made. As to the specific topics that Craig mentions: - CSRG was not tasked by DARPA "to put a VM into Unix”. Having done that with BSD3 and 4.0 made them credible as a contract partner for DARPA. It is correct though that the CSRG contract did *not* include the development of a TCP/IP stack. - I am uncertain on the importance of “mbufs”. Craig sees this as a major innovation (and Clem seems to be of this opinion as well). Personally, I don’t see it. The 1975 NCP Unix already uses a scheme to create 64-byte buffers out of 512 byte disk buffers and the 1979 V7 Unix packet driver does something similar. Changing that to take space from the page manager instead does not seem like a big conceptual leap to me. The other innovation is the use of a “start” pointer with each buffer next to the “len” parameter. This allows to chop off protocol headers without copying. Slightly similar earlier work exists. - "Rob also redid the code to work with software interrupts”. This is true, but misleading. The original BBN code used a separate kernel process to run the network code, not software interrupts. That I have first seen in the CSRG code. Later on, the BBN code was reworked to use software interrupts as well. Doing it this way is necessary on fast networks, as integrating the quick service of the network kernel process with regular process scheduling is too hard / slow. - Bill Joy did rewrite the BBN TCP/IP stack. A few surviving SCCS snippets show that he started with (parts of) the BBN code and rapidly modified that code. Very quickly the result was a new code base, with just a few echoes of the starting point remaining. The original BBN code was neatly layered with an input state machine and many small action routines. This fits with the "portable reference code” purpose. CSRG was writing fast code for fast networks and the early VAX C compiler used a rather slow call sequence. My guess is that this was the main driver for preferring a single, big routine. - The bug compatibility referred to appears to be an “off by one” error in the implementation of out-of-sequence (“urgent”) segments in the TCP stream. Here the BBN code and the CSRG code are off by one versus the spec. This is mentioned in the Comer networking books. Urgent segments in TCP are rarely used (it is easier to just open a second channel) and I don’t think many people encountered this protocol compliance bug in practice. Maybe only in the BBN-CSRG controversy it was important. - It is true that the spec was still maturing at the time. TCP v4 was more or less done in 1979, but the full protocol did not come together until 1982. During that period IP was separated from TCP, UDP and ICMP were introduced, etc. and that this lead to two stacks having to be maintained in parallel. From tuhs at tuhs.org Wed Jan 21 19:41:01 2026 From: tuhs at tuhs.org (Erik E. Fair via TUHS) Date: Wed, 21 Jan 2026 01:41:01 -0800 Subject: [TUHS] Craig Partridge on BBN vs BSD TCP/IP In-Reply-To: <0BEC1C8D-17AB-4828-8E66-20ABDA4622DC@planet.nl> Message-ID: <16666.1768988461@cesium.clock.org> Two very commonly used (at the time) Unix network applications which use TCP urgent (out of band): telnet(1) and rlogin(1). There is mirrored code in their respective daemon counterparts, too. The NetBSD source code for telnetd(8) contains a couple of mitigations for the off-by-one urgent data bug, some marked by /* XXX */ comments, in state.c, telnetd.c, and utility.c See https://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/telnetd/ Erik From tuhs at tuhs.org Wed Jan 21 21:02:30 2026 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Wed, 21 Jan 2026 12:02:30 +0100 Subject: [TUHS] Craig Partridge on BBN vs BSD TCP/IP In-Reply-To: <16666.1768988461@cesium.clock.org> References: <16666.1768988461@cesium.clock.org> Message-ID: <579B13F8-941A-40BE-81DD-22D00A93D4EC@planet.nl> > On 21 Jan 2026, at 10:41, Erik E. Fair wrote: > > Two very commonly used (at the time) Unix network applications which use TCP urgent (out of band): telnet(1) and rlogin(1). There is mirrored code in their respective daemon counterparts, too. > > The NetBSD source code for telnetd(8) contains a couple of mitigations for the off-by-one urgent data bug, some marked by /* XXX */ comments, in state.c, telnetd.c, and utility.c > > See https://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/telnetd/ > > Erik Ah, did not know that. Thanks! From tuhs at tuhs.org Thu Jan 22 00:51:16 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Wed, 21 Jan 2026 06:51:16 -0800 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: <17274.1768961289@cesium.clock.org> References: <17274.1768961289@cesium.clock.org> Message-ID: <20260121145116.GA4270@mcvoy.com> On Tue, Jan 20, 2026 at 06:08:09PM -0800, Erik E. Fair via TUHS wrote: > Clem, do you want to chime in here to describe MassComp's extravagant > solution to that? I think I sort of know what they did. They ran 2 68k cpus in lock step, with one some number of instructions behind. When the leading CPU faulted, it stopped the other one before it ran the instruction that faulted, the stopped one somehow was redirected to handle the fault. I feel like Forest Baskett may have been involved in that idea, maybe he did it first elsewhere? Anyone know? Clem will chime in with the correct details. From tuhs at tuhs.org Thu Jan 22 01:38:27 2026 From: tuhs at tuhs.org (Rich Salz via TUHS) Date: Wed, 21 Jan 2026 10:38:27 -0500 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: <20260121145116.GA4270@mcvoy.com> References: <17274.1768961289@cesium.clock.org> <20260121145116.GA4270@mcvoy.com> Message-ID: On Wed, Jan 21, 2026 at 9:51 AM Larry McVoy via TUHS wrote: > I think I sort of know what they did. They ran 2 68k cpus in lock step, > with one some number of instructions behind. When the leading CPU > faulted, it stopped the other one before it ran the instruction that > faulted, the stopped one somehow was redirected to handle the fault. Apollo did something similar. If the first CPU faulted, the second would halt it, page in the memory and restart the first one. From tuhs at tuhs.org Thu Jan 22 01:47:40 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Wed, 21 Jan 2026 07:47:40 -0800 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: References: <17274.1768961289@cesium.clock.org> <20260121145116.GA4270@mcvoy.com> Message-ID: <20260121154740.GB4270@mcvoy.com> On Wed, Jan 21, 2026 at 10:38:27AM -0500, Rich Salz wrote: > On Wed, Jan 21, 2026 at 9:51???AM Larry McVoy via TUHS wrote: > > > I think I sort of know what they did. They ran 2 68k cpus in lock step, > > with one some number of instructions behind. When the leading CPU > > faulted, it stopped the other one before it ran the instruction that > > faulted, the stopped one somehow was redirected to handle the fault. > > > Apollo did something similar. If the first CPU faulted, the second would > halt it, page in the memory and restart the first one. Yeah, I think it was a pretty standard trick, I just can't remember who came up with it first. My aging memory thinks it was Forest but I may have made that up. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu Jan 22 01:52:35 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Wed, 21 Jan 2026 08:52:35 -0700 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: References: Message-ID: On Tue, Jan 20, 2026 at 12:48 PM Paul Winalski via TUHS wrote: > My question is, did Unix make any use of either supervisor or executive > mode on the VAX? > I know that SGI did use these modes on the MIPS processor. But it was a bit like the 2.11BSD use: They created supervisor mode code for the X server that anybody could call, but mediated the access to the hardware to trusted code. They did this as part of their protocol optional interface to the hardware since 80% of the time was chewed up in protocol things, at least according to a presentation I saw / paper I read about it at one of the X technical conferences. They did this generically to allow a richer interface to devices than a driver could normally provide to userland, as well as hopping on the microkernel bandwagon. It was a good idea, though, since this was basically just a process that ran in a different processor mode, so it was easy to restart if it crashed... Warner From tuhs at tuhs.org Thu Jan 22 01:59:05 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Wed, 21 Jan 2026 08:59:05 -0700 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: References: Message-ID: On Wed, Jan 21, 2026 at 8:52 AM Warner Losh wrote: > > > On Tue, Jan 20, 2026 at 12:48 PM Paul Winalski via TUHS > wrote: > >> My question is, did Unix make any use of either supervisor or executive >> mode on the VAX? >> > > I know that SGI did use these modes on the MIPS processor. But it was a > bit like > the 2.11BSD use: They created supervisor mode code for the X server that > anybody > could call, but mediated the access to the hardware to trusted code. They > did this as > part of their protocol optional interface to the hardware since 80% of the > time was chewed > up in protocol things, at least according to a presentation I saw / paper > I read about > it at one of the X technical conferences. They did this generically to > allow a richer interface > to devices than a driver could normally provide to userland, as well as > hopping on the > microkernel bandwagon. It was a good idea, though, since this was > basically just a process > that ran in a different processor mode, so it was easy to restart if it > crashed... > The AI chat bots seem to think this paper was "A High Performance X Server for a 64-bit Architecture," presented by Silicon Graphics at the 8th X Technical Conference in 1994, But I can't find it online... Anybody know a source? Warner From tuhs at tuhs.org Thu Jan 22 06:55:25 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 22 Jan 2026 06:55:25 +1000 Subject: [TUHS] Fwd: I wish to register a complaint! (about BSD make) Message-ID: ----- Forwarded message from "G. Branden Robinson" ----- Subject: I wish to register a complaint! (about BSD make) [CCing Warren due to my usual GMail->TUHS interference problems] ...that's how my Hungarian phrasebook tells me to word it. Since this issue burns me every time I do a groff release (formerly as deputy maintainer, now as a full bird), I wish to risk offending BSD partisans by griping about their make. Apparently BSD make tracks file identity in its dependency graph by using...strings. That's it. Just strings. So "foo" != "./foo" != "./././foo" and so on. To BSD make, these are different things, even though by design they must be file specifications ("pathnames") _on the file system_, and on every Unix, they _are the same_. So you get spurious build failures when, say, macro contents naming a target disagree with target names in rules in ways that don't make sense when you know what's going on (outside of make implementation details). Let me offer some simplified examples. FOO = ./foo $(FOO): bar frob < bar > $(FOO) If the "./" prefix seems like a silly thing to do, consider that it may itself be the result of macro expansion. FOO = $(BAZ)/foo all: $(FOO) $(FOO): bar frob < bar > $(FOO) $ make BAZ=/look/over/there (Yes, a real Makefile for BSD make would probably not be written this way.[1]) This design is a landmine with a tripwire in front of it because in the shell command "recipes" of a makefile rule, you once again get the semantics you expect as a Unix file system user, because the _shell_ resolves whatever $(FOO) expands to. So it is not fooled by "./" or "./././." or any other variation on that theme. I find this design choice even more confusing because Unix has had hard links since day one, or just about. The _name_ of a file as a string or even a directory entry is not its uniquely identifying characteristic (ignoring content). Why does the BSD make dependency graph not track the device and inode pair instead? And won't this string-based approach fail to detect file identity in the case of symbolic links as well? Didn't BSD _invent_ symbolic links? Can someone make this make sense? Regards, Branden [1] You'd need "BAZ ?= ." to keep "foo" from being sought in the root directory if the macro wasn't defined on make's command line. Or via inclusion, depending on the implementation. But "?=" is new to POSIX 2024 so I suppose that for a long time, one couldn't rely on its availability. ----- End forwarded message ----- From tuhs at tuhs.org Thu Jan 22 07:30:30 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Thu, 22 Jan 2026 08:30:30 +1100 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: <20260121154740.GB4270@mcvoy.com> References: <17274.1768961289@cesium.clock.org> <20260121145116.GA4270@mcvoy.com> <20260121154740.GB4270@mcvoy.com> Message-ID: On Wed, Jan 21, 2026 at 07:47:40AM -0800, Larry McVoy via TUHS wrote: > On Wed, Jan 21, 2026 at 10:38:27AM -0500, Rich Salz wrote: > > On Wed, Jan 21, 2026 at 9:51???AM Larry McVoy via TUHS wrote: > > > > > I think I sort of know what they did. They ran 2 68k cpus in lock step, > > > with one some number of instructions behind. When the leading CPU > > > faulted, it stopped the other one before it ran the instruction that > > > faulted, the stopped one somehow was redirected to handle the fault. > > > > > > Apollo did something similar. If the first CPU faulted, the second would > > halt it, page in the memory and restart the first one. > > Yeah, I think it was a pretty standard trick, I just can't remember who came > up with it first. My aging memory thinks it was Forest but I may have made > that up. Clem mentioned a paper from Forest in https://www.tuhs.org/pipermail/tuhs/2020-January/020130.html Forest Baskett Pascal and Virtual Memory in a Z8000 or MC68000 based Design Station COMPCON 80, Digest of Papers, pp 456-459, IEEE Computer Society, Feb. 25, 1980 Also referenced in https://bitsavers.org/pdf/stanford/sun/The_SUN_Workstation_Draft_Mar80.pdf From tuhs at tuhs.org Thu Jan 22 08:32:28 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 21 Jan 2026 17:32:28 -0500 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: <17274.1768961289@cesium.clock.org> References: <17274.1768961289@cesium.clock.org> Message-ID: below On Tue, Jan 20, 2026 at 9:08 PM Erik E. Fair via TUHS wrote: > > Also, yeah, Bourne shell's ... interesting ... notions of memory > management: SEG fault? Catch it, and sbrk(2)! Doesn't work on the mc68000 > because it didn't keep enough state for restarting faulted instructions > unlike the DEC PDP-11 (Clem, do you want to chime in here to describe > MassComp's extravagant solution to that?). Asa Romberger recounted the tale > of refactoring Bourne shell for mc68000 to me while I was working for Dual > and visiting UniSoft relatively frequently. The mc68010 fixed that > incomplete fault state bug, and made demand-paged virtual memory possible > for mc68k-family-based systems. > To be fair, the idea originated with Forest Baskett's Asilmar paper in 1980, if I remember the date correctly. Sadly, the paper appears to have been lost to time, as far as I can tell. As Erik mentioned, the problem is that the instruction needs to be restarted and allowed to complete — after the VM code makes the page available, it restarts the processor with the original instruction that previously failed. Without getting into too many HW details, there were several types of memory available, each with different characteristics for accessing them. Also, the processors of that day used a synchronous bus -* i.e.*, the processor put an address onto the memory bus and waited for the resulting read or write before the instruction that created the address "complete." [1] Since different memories have different timing characteristics, the 68000 has a "wait state" pin. Depending on how long it has been asserted, it allows N clock cycles to go by while the processor waits for the memory transaction to complete. So the Masscomp MC500 CPU board had 2 68000s on it, called the "executor" and the "fixer." The fixer did just that. It ran the code to fetch a new page for a read or to create a copy of the page on a write, which was in the address space assigned to the process executing on the processor. When an executor "faulted" instead of returning an error, the hardware just sent wait states to it. The fixer set the memory and released the wait pin on the executor, which will complete the requested operation without faulting, but at the expense of a very long time for that instruction to complete on the executor. When Motorola came out with the 68010, which did save enough "microcode" state so the executor could fault and was free to do something else while the fixer redid everything. We swapped out the executor and changed a small amount of logic on the CPU board. The executor was free to do something else while the fixed cared for the memory. When the fixer gave the ok, the executor would pick up where it left off in the process that originally hit the fault. A "fun" (undocumented) feature was discovered by us soon after the 68010 showed up. Masscomp was the first UNIX vendor to build and sell an MP machine (MC500/DP). But we ran into a field issue with the 68010's. It turns out that different microcode was implemented in different "steps" of the chip. And what was saved on the stack was different between them. So the problem was, if a CPU board was made with a 68010 from batch A, and its MP twin CPU board had a 68010 from batch B — thus having slightly different microcode. The issue we discovered was that when the 68010-based executor on CPU card A faulted, the microcode state was stored on the stack per Motorola's specs, but when we tried to restart the process by allowing the previous faulting instruction to be retried, batch B's 68010 executor could not grok the microcode state that had been stored from executor A (and vice versa). After many complaints to our Motorola rep, to get them to make the microstate saved identical even when they "stepped" the processor. In the meantime, manufacturing and field service made the "field replaceable unit" (FRU) a matched set of processor cards. Clem 1] The PDP-11 worked this way, but starting with the Vax and copied by more modern processors is the idea of a "split transaction" bus. where the processor makes a request of the memory system, and is free to do something else. The memory returns a bus transaction indicating whether data was written or read, and the processor can retire the instructions. This is really useful when you start to break up instructions in a pipeline. From tuhs at tuhs.org Thu Jan 22 08:35:25 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 21 Jan 2026 17:35:25 -0500 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: References: <17274.1768961289@cesium.clock.org> Message-ID: Thanks, Jonathan - yes, it was COMPCON to Asilimar. On Wed, Jan 21, 2026 at 5:32 PM Clem Cole wrote: > below > > On Tue, Jan 20, 2026 at 9:08 PM Erik E. Fair via TUHS > wrote: > >> >> Also, yeah, Bourne shell's ... interesting ... notions of memory >> management: SEG fault? Catch it, and sbrk(2)! Doesn't work on the mc68000 >> because it didn't keep enough state for restarting faulted instructions >> unlike the DEC PDP-11 (Clem, do you want to chime in here to describe >> MassComp's extravagant solution to that?). Asa Romberger recounted the tale >> of refactoring Bourne shell for mc68000 to me while I was working for Dual >> and visiting UniSoft relatively frequently. The mc68010 fixed that >> incomplete fault state bug, and made demand-paged virtual memory possible >> for mc68k-family-based systems. >> > To be fair, the idea originated with Forest Baskett's Asilmar paper in > 1980, if I remember the date correctly. Sadly, the paper appears to have > been lost to time, as far as I can tell. As Erik mentioned, the problem is > that the instruction needs to be restarted and allowed to complete — after > the VM code makes the page available, it restarts the processor with the > original instruction that previously failed. > > Without getting into too many HW details, there were several types of > memory available, each with different characteristics for accessing them. > Also, the processors of that day used a synchronous bus -* i.e.*, the > processor put an address onto the memory bus and waited for the resulting > read or write before the instruction that created the address "complete." > [1] Since different memories have different timing characteristics, the > 68000 has a "wait state" pin. Depending on how long it has been asserted, > it allows N clock cycles to go by while the processor waits for the memory > transaction to complete. > > So the Masscomp MC500 CPU board had 2 68000s on it, called the "executor" > and the "fixer." The fixer did just that. It ran the code to fetch a new > page for a read or to create a copy of the page on a write, which was in > the address space assigned to the process executing on the processor. When > an executor "faulted" instead of returning an error, the hardware just sent > wait states to it. The fixer set the memory and released the wait pin on > the executor, which will complete the requested operation without faulting, > but at the expense of a very long time for that instruction to complete on > the executor. > > When Motorola came out with the 68010, which did save enough "microcode" > state so the executor could fault and was free to do something else while > the fixer redid everything. We swapped out the executor and changed a > small amount of logic on the CPU board. The executor was free to do > something else while the fixed cared for the memory. When the fixer gave > the ok, the executor would pick up where it left off in the process that > originally hit the fault. > > A "fun" (undocumented) feature was discovered by us soon after the 68010 > showed up. Masscomp was the first UNIX vendor to build and sell an MP > machine (MC500/DP). But we ran into a field issue with the 68010's. > > It turns out that different microcode was implemented in different > "steps" of the chip. And what was saved on the stack was different > between them. So the problem was, if a CPU board was made with a 68010 > from batch A, and its MP twin CPU board had a 68010 from batch B — thus > having slightly different microcode. The issue we discovered was that > when the 68010-based executor on CPU card A faulted, the microcode state > was stored on the stack per Motorola's specs, but when we tried to restart > the process by allowing the previous faulting instruction to be retried, > batch B's 68010 executor could not grok the microcode state that had been > stored from executor A (and vice versa). > > After many complaints to our Motorola rep, to get them to make the > microstate saved identical even when they "stepped" the processor. In the > meantime, manufacturing and field service made the "field replaceable unit" > (FRU) a matched set of processor cards. > > Clem > > > > > > > > 1] The PDP-11 worked this way, but starting with the Vax and copied by > more modern processors is the idea of a "split transaction" bus. where the > processor makes a request of the memory system, and is free to do something > else. The memory returns a bus transaction indicating whether data was > written or read, and the processor can retire the instructions. This is > really useful when you start to break up instructions in a pipeline. > From tuhs at tuhs.org Thu Jan 22 09:43:55 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Wed, 21 Jan 2026 15:43:55 -0800 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: References: <17274.1768961289@cesium.clock.org> Message-ID: The 68000 didn't have any special logic for inserting wait states; one merely asserted DTACK when the data was actually ready. Thus the cult-status newsletter "DTACK Grounded" - https://en.wikipedia.org/wiki/DTACK_Grounded On Wed, Jan 21, 2026 at 2:51 PM Clem Cole via TUHS wrote: > Thanks, Jonathan - yes, it was COMPCON to Asilimar. > > On Wed, Jan 21, 2026 at 5:32 PM Clem Cole wrote: > > > below > > > > On Tue, Jan 20, 2026 at 9:08 PM Erik E. Fair via TUHS > > wrote: > > > >> > >> Also, yeah, Bourne shell's ... interesting ... notions of memory > >> management: SEG fault? Catch it, and sbrk(2)! Doesn't work on the > mc68000 > >> because it didn't keep enough state for restarting faulted instructions > >> unlike the DEC PDP-11 (Clem, do you want to chime in here to describe > >> MassComp's extravagant solution to that?). Asa Romberger recounted the > tale > >> of refactoring Bourne shell for mc68000 to me while I was working for > Dual > >> and visiting UniSoft relatively frequently. The mc68010 fixed that > >> incomplete fault state bug, and made demand-paged virtual memory > possible > >> for mc68k-family-based systems. > >> > > To be fair, the idea originated with Forest Baskett's Asilmar paper in > > 1980, if I remember the date correctly. Sadly, the paper appears to have > > been lost to time, as far as I can tell. As Erik mentioned, the problem > is > > that the instruction needs to be restarted and allowed to complete — > after > > the VM code makes the page available, it restarts the processor with the > > original instruction that previously failed. > > > > Without getting into too many HW details, there were several types of > > memory available, each with different characteristics for accessing them. > > Also, the processors of that day used a synchronous bus -* i.e.*, the > > processor put an address onto the memory bus and waited for the resulting > > read or write before the instruction that created the address "complete." > > [1] Since different memories have different timing characteristics, the > > 68000 has a "wait state" pin. Depending on how long it has been asserted, > > it allows N clock cycles to go by while the processor waits for the > memory > > transaction to complete. > > > > So the Masscomp MC500 CPU board had 2 68000s on it, called the "executor" > > and the "fixer." The fixer did just that. It ran the code to fetch a > new > > page for a read or to create a copy of the page on a write, which was in > > the address space assigned to the process executing on the processor. > When > > an executor "faulted" instead of returning an error, the hardware just > sent > > wait states to it. The fixer set the memory and released the wait pin on > > the executor, which will complete the requested operation without > faulting, > > but at the expense of a very long time for that instruction to complete > on > > the executor. > > > > When Motorola came out with the 68010, which did save enough "microcode" > > state so the executor could fault and was free to do something else while > > the fixer redid everything. We swapped out the executor and changed a > > small amount of logic on the CPU board. The executor was free to do > > something else while the fixed cared for the memory. When the fixer gave > > the ok, the executor would pick up where it left off in the process that > > originally hit the fault. > > > > A "fun" (undocumented) feature was discovered by us soon after the 68010 > > showed up. Masscomp was the first UNIX vendor to build and sell an MP > > machine (MC500/DP). But we ran into a field issue with the 68010's. > > > > It turns out that different microcode was implemented in different > > "steps" of the chip. And what was saved on the stack was different > > between them. So the problem was, if a CPU board was made with a 68010 > > from batch A, and its MP twin CPU board had a 68010 from batch B — thus > > having slightly different microcode. The issue we discovered was that > > when the 68010-based executor on CPU card A faulted, the microcode state > > was stored on the stack per Motorola's specs, but when we tried to > restart > > the process by allowing the previous faulting instruction to be retried, > > batch B's 68010 executor could not grok the microcode state that had been > > stored from executor A (and vice versa). > > > > After many complaints to our Motorola rep, to get them to make the > > microstate saved identical even when they "stepped" the processor. In > the > > meantime, manufacturing and field service made the "field replaceable > unit" > > (FRU) a matched set of processor cards. > > > > Clem > > > > > > > > > > > > > > > > 1] The PDP-11 worked this way, but starting with the Vax and copied by > > more modern processors is the idea of a "split transaction" bus. where > the > > processor makes a request of the memory system, and is free to do > something > > else. The memory returns a bus transaction indicating whether data was > > written or read, and the processor can retire the instructions. This is > > really useful when you start to break up instructions in a pipeline. > > > From tuhs at tuhs.org Thu Jan 22 09:48:38 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 21 Jan 2026 18:48:38 -0500 Subject: [TUHS] Unix use of VAX protection modes In-Reply-To: References: <17274.1768961289@cesium.clock.org> Message-ID: Ah yes. Thank you. I had forgotten, unlike some the other contemporary chips, the 68000 just waits for the memory system to tell it to continue. The faster the access time on your memory, the faster it could complete the instructions. Sent from a handheld expect more typos than usual On Wed, Jan 21, 2026 at 6:44 PM Tom Lyon wrote: > The 68000 didn't have any special logic for inserting wait states; one > merely asserted DTACK when the data was actually ready. > Thus the cult-status newsletter "DTACK Grounded" - > https://en.wikipedia.org/wiki/DTACK_Grounded > > On Wed, Jan 21, 2026 at 2:51 PM Clem Cole via TUHS wrote: > >> Thanks, Jonathan - yes, it was COMPCON to Asilimar. >> >> On Wed, Jan 21, 2026 at 5:32 PM Clem Cole wrote: >> >> > below >> > >> > On Tue, Jan 20, 2026 at 9:08 PM Erik E. Fair via TUHS >> > wrote: >> > >> >> >> >> Also, yeah, Bourne shell's ... interesting ... notions of memory >> >> management: SEG fault? Catch it, and sbrk(2)! Doesn't work on the >> mc68000 >> >> because it didn't keep enough state for restarting faulted instructions >> >> unlike the DEC PDP-11 (Clem, do you want to chime in here to describe >> >> MassComp's extravagant solution to that?). Asa Romberger recounted the >> tale >> >> of refactoring Bourne shell for mc68000 to me while I was working for >> Dual >> >> and visiting UniSoft relatively frequently. The mc68010 fixed that >> >> incomplete fault state bug, and made demand-paged virtual memory >> possible >> >> for mc68k-family-based systems. >> >> >> > To be fair, the idea originated with Forest Baskett's Asilmar paper in >> > 1980, if I remember the date correctly. Sadly, the paper appears to >> have >> > been lost to time, as far as I can tell. As Erik mentioned, the >> problem is >> > that the instruction needs to be restarted and allowed to complete — >> after >> > the VM code makes the page available, it restarts the processor with the >> > original instruction that previously failed. >> > >> > Without getting into too many HW details, there were several types of >> > memory available, each with different characteristics for accessing >> them. >> > Also, the processors of that day used a synchronous bus -* i.e.*, the > > >> > processor put an address onto the memory bus and waited for the >> resulting >> > read or write before the instruction that created the address >> "complete." >> > [1] Since different memories have different timing characteristics, the >> > 68000 has a "wait state" pin. Depending on how long it has been >> asserted, >> > it allows N clock cycles to go by while the processor waits for the >> memory >> > transaction to complete. >> > >> > So the Masscomp MC500 CPU board had 2 68000s on it, called the >> "executor" >> > and the "fixer." The fixer did just that. It ran the code to fetch a >> new >> > page for a read or to create a copy of the page on a write, which was in >> > the address space assigned to the process executing on the processor. >> When >> > an executor "faulted" instead of returning an error, the hardware just >> sent >> > wait states to it. The fixer set the memory and released the wait pin >> on >> > the executor, which will complete the requested operation without >> faulting, >> > but at the expense of a very long time for that instruction to complete >> on >> > the executor. >> > >> > When Motorola came out with the 68010, which did save enough "microcode" >> > state so the executor could fault and was free to do something else >> while >> > the fixer redid everything. We swapped out the executor and changed a >> > small amount of logic on the CPU board. The executor was free to do >> > something else while the fixed cared for the memory. When the fixer >> gave >> > the ok, the executor would pick up where it left off in the process that >> > originally hit the fault. >> > >> > A "fun" (undocumented) feature was discovered by us soon after the 68010 >> > showed up. Masscomp was the first UNIX vendor to build and sell an MP >> > machine (MC500/DP). But we ran into a field issue with the 68010's. >> > >> > It turns out that different microcode was implemented in different >> > "steps" of the chip. And what was saved on the stack was different >> > between them. So the problem was, if a CPU board was made with a 68010 >> > from batch A, and its MP twin CPU board had a 68010 from batch B — thus >> > having slightly different microcode. The issue we discovered was that >> > when the 68010-based executor on CPU card A faulted, the microcode state >> > was stored on the stack per Motorola's specs, but when we tried to >> restart >> > the process by allowing the previous faulting instruction to be retried, >> > batch B's 68010 executor could not grok the microcode state that had >> been >> > stored from executor A (and vice versa). >> > >> > After many complaints to our Motorola rep, to get them to make the >> > microstate saved identical even when they "stepped" the processor. In >> the >> > meantime, manufacturing and field service made the "field replaceable >> unit" >> > (FRU) a matched set of processor cards. >> > >> > Clem >> > >> > >> > >> > >> > >> > >> > >> > 1] The PDP-11 worked this way, but starting with the Vax and copied by >> > more modern processors is the idea of a "split transaction" bus. where >> the >> > processor makes a request of the memory system, and is free to do >> something >> > else. The memory returns a bus transaction indicating whether data was >> > written or read, and the processor can retire the instructions. This is >> > really useful when you start to break up instructions in a pipeline. >> > >> > From tuhs at tuhs.org Thu Jan 22 18:20:44 2026 From: tuhs at tuhs.org (Roberto E. Vargas Caballero via TUHS) Date: Thu, 22 Jan 2026 09:20:44 +0100 Subject: [TUHS] Fwd: I wish to register a complaint! (about BSD make) In-Reply-To: References: Message-ID: Hi, On Thu, Jan 22, 2026 at 06:55:25AM +1000, Warren Toomey via TUHS wrote: > [1] You'd need "BAZ ?= ." to keep "foo" from being sought in the root > directory if the macro wasn't defined on make's command line. Or > via inclusion, depending on the implementation. > > But "?=" is new to POSIX 2024 so I suppose that for a long time, one > couldn't rely on its availability. "BAZ = ." works for that use case. The only difference is that ?= is more like make -e, and ?= gives preference to the environment variable. With = command line has precedence over variables declared in the makefile, but variables in the makefile have precedence over environment variables. Regards, From tuhs at tuhs.org Sun Jan 25 14:49:27 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 25 Jan 2026 14:49:27 +1000 Subject: [TUHS] 1994 Usenix Playing Cards Message-ID: All: https://www.tuhs.org/Archive/Memorabilia/Usenix_Playing_Cards/ Ben Greenfield just scanned these in and sent them to me :-) Thanks Ben!! Cheers, Warren From tuhs at tuhs.org Sun Jan 25 15:03:13 2026 From: tuhs at tuhs.org (Jason T via TUHS) Date: Sat, 24 Jan 2026 23:03:13 -0600 Subject: [TUHS] 1994 Usenix Playing Cards In-Reply-To: References: Message-ID: On Sat, Jan 24, 2026 at 10:49 PM Warren Toomey via TUHS wrote: > All: https://www.tuhs.org/Archive/Memorabilia/Usenix_Playing_Cards/ > > Ben Greenfield just scanned these in and sent them to me :-) > > Reading the .txt file there, Ben says he got them at an auction "to raise money to support the move of the Computer History Museum's move from Boston to San Jose". If it's the same one where I bid on and won a copy of _Computer Lib_, that was probably 1995 or? j From tuhs at tuhs.org Sun Jan 25 15:19:56 2026 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Sun, 25 Jan 2026 05:19:56 +0000 Subject: [TUHS] 1994 Usenix Playing Cards In-Reply-To: References: Message-ID: On Jan 24, 2026, at 21:49, Warren Toomey wrote: > All: https://www.tuhs.org/Archive/Memorabilia/Usenix_Playing_Cards/ > > Ben Greenfield just scanned these in and sent them to me :-) > > Thanks Ben!! Hi Warren, I have an identical deck and I’ve uploaded the photos I took to the same directory. Rob Ricci gave it to me on 7 November 2025 after the start of my research into the UNIX V4 tape. I believe some Utah researchers were involved with this USENIX and this is from leftover stock. I’m happy to scan them at 600 dpi with our scanner, like the UNIX documents I’ve put up on the Internet Archive. https://archive.org/details/@archibits Thalia From tuhs at tuhs.org Sun Jan 25 15:40:27 2026 From: tuhs at tuhs.org (Ori Kuttner via TUHS) Date: Sun, 25 Jan 2026 07:40:27 +0200 Subject: [TUHS] 1994 Usenix Playing Cards In-Reply-To: References: Message-ID: I wonder how it was decided which person will be on which card :-) -- Ori Kuttner CEO Helicon Books http://www.heliconbooks.com On Sun, Jan 25, 2026 at 7:20 AM Thalia Archibald via TUHS wrote: > On Jan 24, 2026, at 21:49, Warren Toomey wrote: > > All: https://www.tuhs.org/Archive/Memorabilia/Usenix_Playing_Cards/ > > > > Ben Greenfield just scanned these in and sent them to me :-) > > > > Thanks Ben!! > > Hi Warren, > > I have an identical deck and I’ve uploaded the photos I took to the same > directory. > > Rob Ricci gave it to me on 7 November 2025 after the start of my research > into > the UNIX V4 tape. I believe some Utah researchers were involved with this > USENIX > and this is from leftover stock. > > I’m happy to scan them at 600 dpi with our scanner, like the UNIX > documents I’ve > put up on the Internet Archive. > https://archive.org/details/@archibits > > Thalia > > From tuhs at tuhs.org Mon Jan 26 03:48:55 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Sun, 25 Jan 2026 17:48:55 +0000 Subject: [TUHS] 1994 Usenix Playing Cards In-Reply-To: References: Message-ID: Thank you, Warren, for sharing, These are absolutely classic, I really enjoyed looking at them. Using this pack for an actual game would be distracting from a UNIX nerd point of view though, I suspect :-) Best regards, Cameron -------- Original Message -------- On Sunday, 01/25/26 at 04:49 Warren Toomey via TUHS wrote: All: https://www.tuhs.org/Archive/Memorabilia/Usenix_Playing_Cards/ Ben Greenfield just scanned these in and sent them to me :-) Thanks Ben!! Cheers, Warren From tuhs at tuhs.org Mon Jan 26 04:29:04 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Sun, 25 Jan 2026 13:29:04 -0500 Subject: [TUHS] 1994 Usenix Playing Cards In-Reply-To: References: Message-ID: It was all Peter Weinberger's doing. I still have that deck somewhere in my apartment. I wonder if I can find it ... ===== mindthegapdialogs.com north-fork.info On Sun, Jan 25, 2026 at 1:06 PM Ori Kuttner via TUHS wrote: > I wonder how it was decided which person will be on which card :-) > > -- > Ori Kuttner CEO Helicon Books > http://www.heliconbooks.com > > > > > > On Sun, Jan 25, 2026 at 7:20 AM Thalia Archibald via TUHS > wrote: > > > On Jan 24, 2026, at 21:49, Warren Toomey wrote: > > > All: https://www.tuhs.org/Archive/Memorabilia/Usenix_Playing_Cards/ > > > > > > Ben Greenfield just scanned these in and sent them to me :-) > > > > > > Thanks Ben!! > > > > Hi Warren, > > > > I have an identical deck and I’ve uploaded the photos I took to the same > > directory. > > > > Rob Ricci gave it to me on 7 November 2025 after the start of my research > > into > > the UNIX V4 tape. I believe some Utah researchers were involved with this > > USENIX > > and this is from leftover stock. > > > > I’m happy to scan them at 600 dpi with our scanner, like the UNIX > > documents I’ve > > put up on the Internet Archive. > > https://archive.org/details/@archibits > > > > Thalia > > > > > From tuhs at tuhs.org Mon Jan 26 05:16:29 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Sun, 25 Jan 2026 12:16:29 -0700 Subject: [TUHS] 1994 Usenix Playing Cards In-Reply-To: References: Message-ID: <202601251916.60PJGTFJ017464@freefriends.org> What do you mean? What's the story? Thanks, Arnold Marc Donner via TUHS wrote: > It was all Peter Weinberger's doing. > > I still have that deck somewhere in my apartment. I wonder if I can find > it ... > ===== > mindthegapdialogs.com > north-fork.info > > > On Sun, Jan 25, 2026 at 1:06 PM Ori Kuttner via TUHS wrote: > > > I wonder how it was decided which person will be on which card :-) > > > > -- > > Ori Kuttner CEO Helicon Books > > http://www.heliconbooks.com > > > > > > > > > > > > On Sun, Jan 25, 2026 at 7:20 AM Thalia Archibald via TUHS > > wrote: > > > > > On Jan 24, 2026, at 21:49, Warren Toomey wrote: > > > > All: https://www.tuhs.org/Archive/Memorabilia/Usenix_Playing_Cards/ > > > > > > > > Ben Greenfield just scanned these in and sent them to me :-) > > > > > > > > Thanks Ben!! > > > > > > Hi Warren, > > > > > > I have an identical deck and I’ve uploaded the photos I took to the same > > > directory. > > > > > > Rob Ricci gave it to me on 7 November 2025 after the start of my research > > > into > > > the UNIX V4 tape. I believe some Utah researchers were involved with this > > > USENIX > > > and this is from leftover stock. > > > > > > I’m happy to scan them at 600 dpi with our scanner, like the UNIX > > > documents I’ve > > > put up on the Internet Archive. > > > https://archive.org/details/@archibits > > > > > > Thalia > > > > > > > > From tuhs at tuhs.org Mon Jan 26 05:45:05 2026 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Sun, 25 Jan 2026 14:45:05 -0500 Subject: [TUHS] 1994 Usenix Playing Cards In-Reply-To: <202601251916.60PJGTFJ017464@freefriends.org> References: <202601251916.60PJGTFJ017464@freefriends.org> Message-ID: Sorry, you don't know my sense of humor. I was joking. I saw Peter Weinberger's name on the Joker, that's all. I do not recall that Peter was much involved in USENIX. I'll ask him when I next see him. ===== mindthegapdialogs.com north-fork.info On Sun, Jan 25, 2026 at 2:16 PM wrote: > What do you mean? What's the story? > > Thanks, > > Arnold > > Marc Donner via TUHS wrote: > > > It was all Peter Weinberger's doing. > > > > I still have that deck somewhere in my apartment. I wonder if I can find > > it ... > > ===== > > mindthegapdialogs.com > > north-fork.info > > > > > > On Sun, Jan 25, 2026 at 1:06 PM Ori Kuttner via TUHS > wrote: > > > > > I wonder how it was decided which person will be on which card :-) > > > > > > -- > > > Ori Kuttner CEO Helicon Books > > > http://www.heliconbooks.com > > > > > > > > > > > > > > > > > > On Sun, Jan 25, 2026 at 7:20 AM Thalia Archibald via TUHS < > tuhs at tuhs.org> > > > wrote: > > > > > > > On Jan 24, 2026, at 21:49, Warren Toomey wrote: > > > > > All: > https://www.tuhs.org/Archive/Memorabilia/Usenix_Playing_Cards/ > > > > > > > > > > Ben Greenfield just scanned these in and sent them to me :-) > > > > > > > > > > Thanks Ben!! > > > > > > > > Hi Warren, > > > > > > > > I have an identical deck and I’ve uploaded the photos I took to the > same > > > > directory. > > > > > > > > Rob Ricci gave it to me on 7 November 2025 after the start of my > research > > > > into > > > > the UNIX V4 tape. I believe some Utah researchers were involved with > this > > > > USENIX > > > > and this is from leftover stock. > > > > > > > > I’m happy to scan them at 600 dpi with our scanner, like the UNIX > > > > documents I’ve > > > > put up on the Internet Archive. > > > > https://archive.org/details/@archibits > > > > > > > > Thalia > > > > > > > > > > > > From tuhs at tuhs.org Mon Jan 26 20:30:07 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 26 Jan 2026 03:30:07 -0700 Subject: [TUHS] 1994 Usenix Playing Cards In-Reply-To: References: <202601251916.60PJGTFJ017464@freefriends.org> Message-ID: <202601261030.60QAU71G083747@freefriends.org> Ah. Sort of like EGREG in the later Research versions. :-) Marc Donner wrote: > Sorry, you don't know my sense of humor. I was joking. > > I saw Peter Weinberger's name on the Joker, that's all. > > I do not recall that Peter was much involved in USENIX. I'll ask him when > I next see him. > ===== > mindthegapdialogs.com > north-fork.info > > > On Sun, Jan 25, 2026 at 2:16 PM wrote: > > > What do you mean? What's the story? > > > > Thanks, > > > > Arnold > > > > Marc Donner via TUHS wrote: > > > > > It was all Peter Weinberger's doing. > > > > > > I still have that deck somewhere in my apartment. I wonder if I can find > > > it ... > > > ===== > > > mindthegapdialogs.com > > > north-fork.info > > > > > > > > > On Sun, Jan 25, 2026 at 1:06 PM Ori Kuttner via TUHS > > wrote: > > > > > > > I wonder how it was decided which person will be on which card :-) > > > > > > > > -- > > > > Ori Kuttner CEO Helicon Books > > > > http://www.heliconbooks.com > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jan 25, 2026 at 7:20 AM Thalia Archibald via TUHS < > > tuhs at tuhs.org> > > > > wrote: > > > > > > > > > On Jan 24, 2026, at 21:49, Warren Toomey wrote: > > > > > > All: > > https://www.tuhs.org/Archive/Memorabilia/Usenix_Playing_Cards/ > > > > > > > > > > > > Ben Greenfield just scanned these in and sent them to me :-) > > > > > > > > > > > > Thanks Ben!! > > > > > > > > > > Hi Warren, > > > > > > > > > > I have an identical deck and I’ve uploaded the photos I took to the > > same > > > > > directory. > > > > > > > > > > Rob Ricci gave it to me on 7 November 2025 after the start of my > > research > > > > > into > > > > > the UNIX V4 tape. I believe some Utah researchers were involved with > > this > > > > > USENIX > > > > > and this is from leftover stock. > > > > > > > > > > I’m happy to scan them at 600 dpi with our scanner, like the UNIX > > > > > documents I’ve > > > > > put up on the Internet Archive. > > > > > https://archive.org/details/@archibits > > > > > > > > > > Thalia > > > > > > > > > > > > > > > > From tuhs at tuhs.org Wed Jan 28 09:46:52 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 27 Jan 2026 23:46:52 +0000 Subject: [TUHS] Earliest Non-English UNIX? Message-ID: I recently got a Japanese copy of the SVR3 Programmer's Reference Manual as a reference on learning technical translation between Japanese and English. It got me wondering on the subject of Japanese UNIX again, and I recall some prior discussion about codepages and eventual UTF-8 use for this and other regional porting efforts, but UNIX use in non-English settings certainly predates UTF-8. From what I know of the Japanese situation, at least AT&T, Sony, and Sun were prominent players in the Japanese UNIX market early on. This has me curious more generally, are there good records on how UNIX became cosmopolitan, what non-English (and especially non-Latin) languages it was first translated into, and how involved, if at all, Bell Labs and UCB (as opposed to post divestiture ATTIS/USL) were in early efforts to localize UNIX outside of the anglophone world. Possibly related, the typo(I) page from V3 makes a quip about disabling the "English" mode to instead target other languages such as Urdu. Urdu is written in an Arabic-derived script rather than Latin. Was this just a "hey this is possible" quip or was that to suggest there was experience already by V3 of playing with non-Latin scripts in UNIX? - Matt G. From tuhs at tuhs.org Wed Jan 28 10:11:26 2026 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Tue, 27 Jan 2026 16:11:26 -0800 Subject: [TUHS] Earliest Non-English UNIX? In-Reply-To: References: Message-ID: On 1/27/26 15:46, segaloco via TUHS wrote: > but UNIX use in non-English settings certainly predates UTF-8 For SunOS/Solaris, before Unicode, it was primarily ISO-8859-* for the European languages, and Extended Unix Code (EUC) for the CJK set. See https://en.wikipedia.org/wiki/Extended_Unix_Code and the EUC section of _Creating Worldwide Software: Solaris International Developer's Guide_ (available at https://archive.org/details/creatingworldwid0000tuth ) for details on EUC. While we've deprecated those locales now in favor of the UTF-8 locales in Solaris 11.0 and later, they're still around, and the character sets supported in things like iconv to allow translating documents, and we know there are still some customers using the EUC locales today. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From tuhs at tuhs.org Wed Jan 28 20:19:51 2026 From: tuhs at tuhs.org (Edouard Klein via TUHS) Date: Wed, 28 Jan 2026 11:19:51 +0100 Subject: [TUHS] Earliest Non-English UNIX? In-Reply-To: (segaloco via TUHS's message of "Tue, 27 Jan 2026 23:46:52 +0000") References: Message-ID: <87h5s6jayg.fsf@gmail.com> For reference the earlier thread was https://www.tuhs.org/pipermail/tuhs/2023-March/028243.html "[TUHS] Bell Foreign-Language UNIX Efforts" in which I posted a history of France's Bull efforts to internationalize UNIX in French, and also in Russian (!) for siberian gas fields: https://www.tuhs.org/pipermail/tuhs/2023-March/028248.html But that was quite a bit later (late 80s, early 90s) than what Matt is asking here. The whole thread is worth a read. Looking forward to reading this one as well to see if more comes up. Cheers, Edouard. segaloco via TUHS writes: > I recently got a Japanese copy of the SVR3 Programmer's Reference Manual as a > reference on learning technical translation between Japanese and English. It got > me wondering on the subject of Japanese UNIX again, and I recall some prior > discussion about codepages and eventual UTF-8 use for this and other regional > porting efforts, but UNIX use in non-English settings certainly predates UTF-8. > From what I know of the Japanese situation, at least AT&T, Sony, and Sun were > prominent players in the Japanese UNIX market early on. > > This has me curious more generally, are there good records on how UNIX became > cosmopolitan, what non-English (and especially non-Latin) languages it was first > translated into, and how involved, if at all, Bell Labs and UCB (as opposed to > post divestiture ATTIS/USL) were in early efforts to localize UNIX outside of > the anglophone world. > > Possibly related, the typo(I) page from V3 makes a quip about disabling the > "English" mode to instead target other languages such as Urdu. Urdu is written > in an Arabic-derived script rather than Latin. Was this just a "hey this is > possible" quip or was that to suggest there was experience already by V3 of > playing with non-Latin scripts in UNIX? > > - Matt G. From tuhs at tuhs.org Thu Jan 29 01:07:07 2026 From: tuhs at tuhs.org (Martin via TUHS) Date: Wed, 28 Jan 2026 17:07:07 +0200 Subject: [TUHS] Earliest Non-English UNIX? In-Reply-To: References: Message-ID: <1c8a472f-7a4d-4b21-bcaa-07c7f37e0638@disroot.org> Hello, I would like to mention here not a UNIX per-se but heavily inspired by it, polish Operating System called CROOK written entirely in K-202/MERA-400 assembly language during 1970s and 1980s in Gdansk University of Technology: https://mera400.pl/Galeria CROOK design was dictated by the same universal needs (multitasking, multiuser support, a hierarchical file system, etc) that shaped UNIX. It was build to work with both older peripherals (like tape readers) and newer devices produced for the MERA-400 by companies like Amepol. Development even influenced the design of the MX-16 processor upgrade for the MERA-400. A major digital archaeology project successfully recovered CROOK and other software from original magnetic tapes, i.e: https://hackaday.com/2017/03/03/raiders-of-the-lost-os-reclaiming-a-piece-of-polish-it-history/#more-245582 Team led by Jakub Filipowicz ( https://github.com/jakubfi ) preserved this key piece of Polish IT history and actively documenting now all the archaeology efforts related with hardware/software restoration of MERA400: https://www.youtube.com/@MERA400 The recovered disk images of CROOK-5 are now available for use in the EM400 emulator, i.e.: https://mera400.pl/CROOK-5_-_obraz_dysku Some basic specs of the machine: - 16-bit asynchronous CPU, up to 1 million operations per second - 48-bit hardware floating point - 121 instructions - 1Mword (2MB) total address space - memory segmentation and paging: dedicated memory block for OS + 15 blocks for user programs - 32 interrupts (maskable, 10 priority levels) Kind Regards! Martin From tuhs at tuhs.org Fri Jan 30 11:12:21 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Fri, 30 Jan 2026 11:12:21 +1000 Subject: [TUHS] V4 in the Unix Archive, Finally Message-ID: Hi all, sorry for the delay but I've just added V4 to the Unix Archive here: https://www.tuhs.org/Archive/Distributions/Research/Utah_v4/ Thanks to everybody involved in finding the tape, recovering its contents, uploading them to archive.org and then doing the subsequent analysis. I will also incorporate the files into the Unix Tree. I just have to rebuild it from scratch and it is going to take a few hours. Details soon. Cheers, Warren From tuhs at tuhs.org Fri Jan 30 12:57:38 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Fri, 30 Jan 2026 12:57:38 +1000 Subject: [TUHS] V4 in the Unix Archive, Finally In-Reply-To: References: Message-ID: On Fri, Jan 30, 2026 at 11:12:21AM +1000, Warren Toomey via TUHS wrote: > Hi all, sorry for the delay but I've just added V4 to the Unix Archive here: > > https://www.tuhs.org/Archive/Distributions/Research/Utah_v4/ And it's also now in the Unix Tree at https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4 Cheers, Warren From tuhs at tuhs.org Sat Jan 31 03:17:40 2026 From: tuhs at tuhs.org (Briam Rodriguez via TUHS) Date: Fri, 30 Jan 2026 12:17:40 -0500 Subject: [TUHS] V4 in the Unix Archive, Finally In-Reply-To: References: Message-ID: Amazing. Thank you! -- Briam R. On 1/29/26 9:57 PM, Warren Toomey via TUHS wrote: > On Fri, Jan 30, 2026 at 11:12:21AM +1000, Warren Toomey via TUHS wrote: >> Hi all, sorry for the delay but I've just added V4 to the Unix Archive here: >> >> https://www.tuhs.org/Archive/Distributions/Research/Utah_v4/ > And it's also now in the Unix Tree at > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4 > > Cheers, Warren From tuhs at tuhs.org Sat Jan 31 04:08:30 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 30 Jan 2026 18:08:30 +0000 Subject: [TUHS] V4 in the Unix Archive, Finally In-Reply-To: References: Message-ID: On Friday, January 30th, 2026 at 09:18, Briam Rodriguez via TUHS wrote: > Amazing. Thank you! > > -- Briam R. > > On 1/29/26 9:57 PM, Warren Toomey via TUHS wrote: > > > On Fri, Jan 30, 2026 at 11:12:21AM +1000, Warren Toomey via TUHS wrote: > > > > > Hi all, sorry for the delay but I've just added V4 to the Unix Archive here: > > > > > > https://www.tuhs.org/Archive/Distributions/Research/Utah_v4/ > > > And it's also now in the Unix Tree at > > > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4 > > > > Cheers, Warren Regarding the V4 manpage sources, would it be appropriate to merge those with this entry in the tree at /usr/man? At the very least the blurb on the root directory should then probably mention the providence of the two pieces and their being amalgamated for tree reasons. - Matt G. From tuhs at tuhs.org Sat Jan 31 07:52:22 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sat, 31 Jan 2026 07:52:22 +1000 Subject: [TUHS] Mix Utah V4 and the V4 Man Pages In-Reply-To: References: Message-ID: On 1/29/26 9:57 PM, Warren Toomey via TUHS wrote: > Hi all, sorry for the delay but I've just added V4 to the Unix Archive here: > > https://www.tuhs.org/Archive/Distributions/Research/Utah_v4/ > > And it's also now in the Unix Tree at > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4 On Fri, Jan 30, 2026 at 06:08:30PM +0000, segaloco via TUHS wrote: > Regarding the V4 manpage sources, would it be appropriate to merge those > with this entry in the tree at /usr/man? At the very least the blurb on > the root directory should then probably mention the providence of the > two pieces and their being amalgamated for tree reasons. I wasn't sure if I should mix the V4 manuals from https://www.tuhs.org/Archive/Distributions/Research/Dennis_v4/ with the Utah tape as there is no nroff on the Utah tape but the man pages are written in nroff. But, yes, I can add some blurb that explains the amalgamation. So, a related question, does anybody know why nroff was _not_ on the Utah V4 tape, especially as it was a late snapshot of V4? Does this also mean that Research kept a "working" version of Unix with their usernames/passwords/working files etc. and somehow ken would "cut" a tape with an RK05 image that came from a separate system? Cheers, Warren From tuhs at tuhs.org Sat Jan 31 09:01:17 2026 From: tuhs at tuhs.org (Bob Myers via TUHS) Date: Fri, 30 Jan 2026 17:01:17 -0600 Subject: [TUHS] A few questions about Unix operation References: <9f0eb5ee-9a99-426d-9ff9-b97753d5139c.ref@yahoo.com> Message-ID: <9f0eb5ee-9a99-426d-9ff9-b97753d5139c@yahoo.com> I have a few general questions about Unix support/operation: 1) is tty0 dedicated for console operation?  Other ttys assigned to serial ports? 2) Can printing be assigned to serial tty ports?  (I'm awaiting an 8-port Serial card to show up next week. I'll run into more questions after I get the serial card and Zuluscsi Blaster installed next week in my PDP-11/83 and obtain a BSD-2.11 image. From tuhs at tuhs.org Sat Jan 31 09:39:03 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Fri, 30 Jan 2026 23:39:03 +0000 Subject: [TUHS] A few questions about Unix operation In-Reply-To: <9f0eb5ee-9a99-426d-9ff9-b97753d5139c@yahoo.com> References: <9f0eb5ee-9a99-426d-9ff9-b97753d5139c.ref@yahoo.com> <9f0eb5ee-9a99-426d-9ff9-b97753d5139c@yahoo.com> Message-ID: If you’re talking about an 11/83 and 2 BSD, the console is /dev/tty8. The BSD lpd could indeed deal with printers on serial ports. ------ Original Message ------ >From "Bob Myers via TUHS" To tuhs at tuhs.org Date 1/30/2026 6:01:17 PM Subject [TUHS] A few questions about Unix operation >I have a few general questions about Unix support/operation: > >1) is tty0 dedicated for console operation? Other ttys assigned to serial ports? > >2) Can printing be assigned to serial tty ports? (I'm awaiting an 8-port Serial card to show up next week. > >I'll run into more questions after I get the serial card and Zuluscsi Blaster installed next week in my PDP-11/83 and obtain a BSD-2.11 image. >