From tuhs at tuhs.org Tue Sep 1 15:03:46 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 31 Aug 2026 23:03:46 -0600 Subject: [TUHS] 32V-x86 Message-ID: Greetings, Going through the old archives, I found references to 32V being ported to x86 in 2003 by Pat Villani and Wesley Parish. The latest I can find is this: > Latest is 32v-031102-01.tar.gz. Available via anonymous ftp at sever.opensourcedepot.com. opensourcedepot.com is parked for sale at $800. There's a reference by Larry McVoy to 32vi.bkbits.net. But work seems to have trailed off in early 2004. So was this effort saved? This effort is unrelated to Robert Nordier's v7x86. When he released it, Pat popped up and reported on his efforts..., but I couldn't find anything else. Anybody save / have a copy? Warner From tuhs at tuhs.org Tue Sep 1 15:37:01 2026 From: tuhs at tuhs.org (Wesley Parish via TUHS) Date: Tue, 1 Sep 2026 17:37:01 +1200 Subject: [TUHS] 32V-x86 In-Reply-To: References: Message-ID: <6034fb7d-e72e-4c55-b0a7-304602224eec@gmail.com> Hi all The last traces of my part of it are on a hard drive that I haven't accessed since 2012. I remember compiling some of the user-level utilities, which proved that gcc could compile source as old as that. But I hadn't done much after that, and I don't think Pat Villani took it any further - he would've been the guy working on the x86-specific stuff. Wesley Parish On 01/09/2026 17:03, Warner Losh via TUHS wrote: > Greetings, > > Going through the old archives, I found references to 32V being ported to > x86 in 2003 by Pat Villani and Wesley Parish. > > The latest I can find is this: >> Latest is 32v-031102-01.tar.gz. Available via anonymous ftp at > sever.opensourcedepot.com. > > opensourcedepot.com is parked for sale at $800. > > There's a reference by Larry McVoy to 32vi.bkbits.net. > > But work seems to have trailed off in early 2004. > > So was this effort saved? > > This effort is unrelated to Robert Nordier's v7x86. When he released it, > Pat popped up and reported on his efforts..., but I couldn't find anything > else. > > Anybody save / have a copy? > > Warner From tuhs at tuhs.org Wed Sep 2 05:15:39 2026 From: tuhs at tuhs.org (andrew--- via TUHS) Date: Tue, 1 Sep 2026 12:15:39 -0700 Subject: [TUHS] mag tapes Message-ID: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> during a belated round of cleanup around the house, i have come across 3 mag tapes: 1) 2400’ reel: cpio 5281x512 blocks, 800 BPI 2) 2400’ reel: cpio -oc 32b, 1600BPI 3) 600(or maybe 800)’ reel: unknown i would REALLY like to get the info of tape 1. all tapes were made around 1980, and have been stored in good residential temp/humidity. where might i be able to process these tapes? or pointers to other places i might ask? andrew hume From tuhs at tuhs.org Wed Sep 2 06:42:06 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 01 Sep 2026 20:42:06 +0000 Subject: [TUHS] mag tapes In-Reply-To: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> References: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> Message-ID: Obviously, getting it off the physical media is key. Once you have the raw records decoding the CPIO is pretty trivial. Hell, my Mac even has cpio on it (haven’t used that in years). Alas, I no gave up all my old collection of tape drives (9 track, QIC, DAT, Exabyte, etc….). The sad truth is that tape is not a long-lived storage format. The fact that this stuff is low density may help. I don’t know who does recovery. I did recover some old real-to-real audio tapes and the company had to “bake” them to make sure they’d unwind. ------ Original Message ------ >From "andrew--- via TUHS" To "The Eunuchs Hysterical Society" Date 9/1/2026 3:15:39 PM Subject [TUHS] mag tapes >during a belated round of cleanup around the house, i have come across 3 mag tapes: > >1) 2400’ reel: cpio 5281x512 blocks, 800 BPI >2) 2400’ reel: cpio -oc 32b, 1600BPI >3) 600(or maybe 800)’ reel: unknown > >i would REALLY like to get the info of tape 1. >all tapes were made around 1980, and have been stored in good residential temp/humidity. > >where might i be able to process these tapes? >or pointers to other places i might ask? > > andrew hume > From tuhs at tuhs.org Wed Sep 2 06:42:08 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 01 Sep 2026 20:42:08 +0000 Subject: [TUHS] mag tapes In-Reply-To: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> References: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> Message-ID: ------ Original Message ------ >From "andrew--- via TUHS" To "The Eunuchs Hysterical Society" Date 9/1/2026 3:15:39 PM Subject [TUHS] mag tapes >during a belated round of cleanup around the house, i have come across 3 mag tapes: > >1) 2400’ reel: cpio 5281x512 blocks, 800 BPI >2) 2400’ reel: cpio -oc 32b, 1600BPI >3) 600(or maybe 800)’ reel: unknown > >i would REALLY like to get the info of tape 1. >all tapes were made around 1980, and have been stored in good residential temp/humidity. > >where might i be able to process these tapes? >or pointers to other places i might ask? > > andrew hume > From tuhs at tuhs.org Wed Sep 2 10:08:24 2026 From: tuhs at tuhs.org (andrew--- via TUHS) Date: Tue, 1 Sep 2026 17:08:24 -0700 Subject: [TUHS] mag tapes In-Reply-To: <20260901151122.1d83f588@TheHughesLogcabin.net> References: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> <20260901151122.1d83f588@TheHughesLogcabin.net> Message-ID: <37F377B1-51B7-4F1B-94CE-5539423730D4@humeweb.com> i am in southern california. > On Sep 1, 2026, at 1:11 PM, Michael Hughes wrote: > > On Tue, 1 Sep 2026 12:15:39 -0700 > andrew--- via TUHS wrote: > >> during a belated round of cleanup around the house, i have come >> across 3 mag tapes: >> >> 1) 2400’ reel: cpio 5281x512 blocks, 800 BPI >> 2) 2400’ reel: cpio -oc 32b, 1600BPI >> 3) 600(or maybe 800)’ reel: unknown >> >> i would REALLY like to get the info of tape 1. >> all tapes were made around 1980, and have been stored in good >> residential temp/humidity. >> >> where might i be able to process these tapes? >> or pointers to other places i might ask? >> >> andrew hume >> >> > > I have two tape drives, one is connected to a VAX 3800 and the other is > an HP SCIS drive that I connect to a FreeBSD system. > > I have pulled data of tapes for other people in the past with the HP > drive. > > Where are you located? > > > -- > Michael D Hughes From tuhs at tuhs.org Wed Sep 2 11:21:44 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Tue, 1 Sep 2026 20:21:44 -0500 Subject: [TUHS] Regex archaeology Message-ID: All, I've been doing some experimentation to test my language, aiki, a small interpreted language. Most of my pressure tests have begun to move toward emulation because emulating machines is challenging in an interpreter (can you say sllllloooooowwwww?). Anyhow, when I had the regex implemented by my outsourced team (claude & chatgpt), I lacked any comprehension of how it actually worked beyond textbook level (which is to say, names of things that I didn't truly comprehend). So, I went looking to primary sources, as I usually do and I came across a sweet little regex implementation by none other than Ken Thompson, in his well known article, Regular Expression Search Algorithm, CACM v. 11, No. 6, June 1968. I found a decent copy and transcribed it so I could use it's examples more directly. It's a piece of work - an Algol 60 three stage program that emits IBM 7094 machine code that processes a string and produces signals. What I really appreciate is that the code "works", it's not a fragment, not partial implementation, but serious work, the core third stage. Anyhow, I wrote a small 7094 processor (only enough instructions to execute thompson's search) in aiki, and tried it out and it's glorious (to me) running the machine code it generates and producing expected results (as provided in this exceptional article). This like all shiny objects took me down a rabbit trail. My language is interpreted remember? I have been thinking about compilers - didn't think I wanted one originally, but man slow is so not me, but not just any implementation. My language is grammar bound, I already have an IR in the AST output, it's closed and therefore, I can prolly just emit it or better yet, follow Thompson with a bytecode emit (something for a go vm, for example). Anyhow, I started wondering, what about algol 60, it's always popping up in any serious language discussion and that took to Randell & Russell's 1964 Algol 60 implementation where translation is discussed, confirming my suspicion on how I might do the compiler for Aiki and preserve it's exact semantic representation and profiling capabilities dtrace style. Then I came back to Thompson, and that's hopefully where y'all come in... Do any of you know what implementation of algol-60 he might have used on the 7094? BC Algol is out in the wild and could be right, but I'm really jazzing to implement the search on an emulated 7094 using an actual algol and preferably the one he was using. I know, on topic? maybe a little stretch for folks only interested in bandying about in the userland/kernel, but regex and it's implementation in ed and elsewhere were surely influenced by this exact work. Thanks! Will From tuhs at tuhs.org Wed Sep 2 12:44:49 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 1 Sep 2026 22:44:49 -0400 Subject: [TUHS] Regex archaeology In-Reply-To: References: Message-ID: Will, CCing COFF and SIMH which is really where this question belongs and BCC: TUHS.org On Tue, Sep 1, 2026 at 9:21 PM Will Senn via TUHS wrote: > All, > > I've been doing some experimentation to test my language, aiki, a small > interpreted language. Most of my pressure tests have begun to move > toward emulation because emulating machines is challenging in an > interpreter (can you say sllllloooooowwwww?). Anyhow, when I had the > regex implemented by my outsourced team (claude & chatgpt), I lacked any > comprehension of how it actually worked beyond textbook level (which is > to say, names of things that I didn't truly comprehend). So, I went > looking to primary sources, as I usually do and I came across a sweet > little regex implementation by none other than Ken Thompson, in his well > known article, Regular Expression Search Algorithm, CACM v. 11, No. 6, > June 1968. I found a decent copy and transcribed it so I could use it's > examples more directly. It's a piece of work - an Algol 60 three stage > program that emits IBM 7094 machine code that processes a string and > produces signals. > > What I really appreciate is that the code "works", it's not a fragment, > not partial implementation, but serious work, the core third stage. > Anyhow, I wrote a small 7094 processor (only enough instructions to > execute thompson's search) in aiki, and tried it out and it's glorious > (to me) running the machine code it generates and producing expected > results (as provided in this exceptional article). > > This like all shiny objects took me down a rabbit trail. My language is > interpreted remember? I have been thinking about compilers - didn't > think I wanted one originally, but man slow is so not me, but not just > any implementation. My language is grammar bound, I already have an IR > in the AST output, it's closed and therefore, I can prolly just emit it > or better yet, follow Thompson with a bytecode emit (something for a go > vm, for example). Anyhow, I started wondering, what about algol 60, it's > always popping up in any serious language discussion and that took to > Randell & Russell's 1964 Algol 60 implementation where translation is > discussed, confirming my suspicion on how I might do the compiler for > Aiki and preserve it's exact semantic representation and profiling > capabilities dtrace style. Then I came back to Thompson, and that's > hopefully where y'all come in... Do any of you know what implementation > of algol-60 he might have used on the 7094? BC Algol is out in the wild > and could be right, but I'm really jazzing to implement the search on an > emulated 7094 using an actual algol and preferably the one he was using. > As I understand it, there are at least three: - IBM ALGOL 60 (System Monitor Compiler) for the IBSYS operating system - SHARE ALGOL 60 Translator targeting the IBM 709/7090/7094 hardware and I thought could run on CTSS - ALCOR ALGOL 60 European-American consortium dedicated to standardized ALGOL deployment for the for the 7090/7094 You might ask Ken what he remembers. I haven't read the paper inm a few years, did he say which OS he was using that might help you track it down. Google tells me that ALCOR-Illinois 7090/7094 compiler project has some influence in CTSS. But it also says: *"**While standard ALGOL 60 dialects like ALCOR existed on the hardware, they were not the primary way people wrote algorithmic code on CTSS day-to-day. CTSS users heavily favored two deeply related "ALGOL-cousin" systems. ... MAD (Michigan Algorithm Decoder - ALGOL 58, and compiled unbelievably fast): was one of the most popular high-level languages on CTSS ... AED (Algol Extended for Design): created at MIT, AED was an explicit, major extension of ALGOL 60 designed specifically to run under CTSS."* > I know, on topic? maybe a little stretch for folks only interested in > bandying about in the userland/kernel, but regex and it's implementation > in ed and elsewhere were surely influenced by this exact work. > > Thanks! > > Will > > From tuhs at tuhs.org Wed Sep 2 13:27:58 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Wed, 02 Sep 2026 03:27:58 +0000 Subject: [TUHS] mag tapes In-Reply-To: (Ron Natalie via TUHS's message of "Tue, 01 Sep 2026 20:42:06 +0000") References: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> Message-ID: <7wwlt449j5.fsf@junk.nocrew.org> Ron Natalie wrote: > Once you have the raw records decoding the CPIO is pretty trivial. You'd think so. But I have come across several cpio tapes that wouldn't decode with a regular modern cpio. So I wrote this. https://github.com/larsbrinkhoff/tools-for-unusual-tape-formats/blob/master/cpio.c From tuhs at tuhs.org Wed Sep 2 21:19:08 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Wed, 2 Sep 2026 07:19:08 -0400 Subject: [TUHS] mag tapes In-Reply-To: References: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> Message-ID: On Tue, Sep 1, 2026 at 4:50 PM Ron Natalie via TUHS wrote: > Obviously, getting it off the physical media is key. Once you have the > raw records decoding the CPIO is pretty trivial. Hell, my Mac even has > cpio on it (haven’t used that in years). > [snip] cpio remains surprisingly relevant in the modern age; I believe the Linux initramfs is a cpio archive, and I know for sure that Oxide machines read a compressed cpio archive out of flash containing the kernel image that initializes our machines (I know because I wrote the code that reads the archive, loads and maps the kernel, and jumps into it to initialize the world; we pull a ramdisk image for the root filesystem off of an NVMe device once we've initialized the PCIe subsystem and kicked off link training and so forth). - Dan C. From tuhs at tuhs.org Fri Sep 4 17:27:05 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 04 Sep 2026 01:27:05 -0600 Subject: [TUHS] Plan 9 C compilers for Linux/mac/windows Message-ID: <202609040727.6847R5xa087700@freefriends.org> This may be of interest to this crowd. NOTE that this is NOT my work, I am simply passing the info on. Arnold > From: yoann.padioleau at gmail.com > To: 9fans <9fans at 9fans.net> > Date: Thu, 3 Sep 2026 16:24:08 -0400 > Subject: [9fans] Goken9cc update, support for Linux, macOS, windows and 11 > archs! > > This is an update for the Goken9cc project I've announced a few months > ago on 9fans (and presented at IWP9): https://github.com/aryx/goken9cc > > To summarize: goken9cc is a portable, multi-architecture toolchain — C > compilers, assemblers, and linkers — together with a minimalist C > library, rooted in Ken Thompson's legendary work on the Plan 9 and > Inferno operating systems. First extended by Go developers, this > toolchain now brings cross-platform support for Linux, macOS, and > Windows while preserving the simplicity, elegance, and efficiency of > the original Plan 9 tools. > > In the future work section of my talk I was talking about the > support to produce Linux ELF binaries, macOS Mach-O binaries, > and windows PE binaries and it's now all working! > > There is also a multiplatform libc similar to the original Plan 9 libc > that can work on 11 architectures (i386, amd64, arm, arm64, riscv32, riscv64, > mips, powerpc, sparc, alpha, m68k) across 4 operating systems (Linux, > darwin, windows, plan9, with xv6 in the work). > > We can now even bootstrap goken using goken, that is using it to compile > itself on Linux, macOS, and windows (and we can still bootstrap it > using gcc and clang, the original goal of goken9cc). > > The included multiplatform libc is pretty complete as it > can be used to compile goken itself which contains not only the toolchain > but also the code of mk, rc, as well as many Plan 9 utilities. > > My plan now is to add a multiplatform libdraw to also produce > Linux, macOS, and windows binaries using graphics (relying on > Russ cox port of libdraw in plan9port and in drawterm). > > Happy to answer questions or requests for the project. > > PS: the code of goken is synced with my other principia softwarica project > so the code of goken is also fully explain in the principia books > at https://principia-softwarica.org/ > > > AI disclaimer: > 95% of the code in goken9cc was written by humans (mostly Ken > Thompson, Rob Pike, Charles Forsyth, Richard Miller, and other Plan 9 > contributors), and for the most part written more than 30 years > ago. What I did was essentially to package those old toolchains > together and then use AI to write the remaining 5% so that the > toolchains could work not just on Plan 9 for Plan 9 but also on and > for Linux, macOS, and Windows (imitating for the most part what was > done by Go developers for the Go language). > > All the clerical work of finding the right syscall numbers for each > architecture and operating systems for the multiplatform C library in > goken9cc (see lib_core/libc/{arch,syscall,os}) was done by Claude > Code, inspired by what Go developers did for Go (see the > GO/pkg/{syscall,runtime} directories). > > Most of the code written by AI is clearly marked with a special > claude: comment at the front and part of a commit authored by Claude > code. You can use the scripts/ai_percentage.py to get authorship LOC > statistics across the different directories in goken9cc. > > ------------------------------------------ > 9fans: 9fans > Permalink: https://9fans.topicbox.com/groups/9fans/T2bd4bdf3bed27839-Mba276412b5bb732bb23582de > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription