Paul, the other thing I should point out -- ghg's work was widely distributed amount the BSD licenses. I somewhat wonder why the Naval Post Grad school's work was not. My guess is that USENIX was still in its formative stages when the latter did their work, whereas, by the time of George's hack, BSD/Vaxen was being used for teaching as University timesharing systems so his 'upgrade' was a cheap solution. ᐧ On Mon, Nov 28, 2022 at 9:05 AM Clem Cole <clemc(a)ccc.com> wrote:

On Mon, Nov 28, 2022 at 7:15 AM Clem Cole <clemc(a)ccc.com> wrote: Also the Naval Post Grad work was on a fairly specialized MP pdp-11/50 system that wasn't super easy to build... plus the paper was declassified, but it's not clear that the code ever was, or even submitted for declassification. It was super early still in the unix sharing culture evolution and wide-spread distribution didn't catch on. Plus, it was for a funky odd custom thing, which limited people wanting to ask for it. Warner

On Mon, Nov 28, 2022 at 9:16 AM Warner Losh <imp(a)bsdimp.com> wrote: Thanks - that makes sense. As I said, I never saw the code, and again, it agrees with my observation that this was 'pre-USENIX,' particularly since I believe that those folks are in CA and the original USENIX people were in NYC and Boston folks, so they would have been less likely to be a part. ᐧ

On Mon, Nov 28, 2022 at 11:30 AM Paul Winalski <paul.winalski(a)gmail.com> wrote: right SBI -- thanks, Paul -- too many TLAs - bad cache refill. no - the Ultrix group never bothered. ᐧ

In 1982, I returned to BRL (having spent a year working for Martin Marietta on project involving a dual process RSX-11M system. I did spend some time setting up the PWB UNIX tools with the QA guys while there). BRL had commissioned the Denver Electronics Corporation (i.e., Denelcor) to build a MIMD system called the HEP, ostensibly to do fluid dynamics problems. It was looking like the manufacturer wasn’t going to have a useful OS for it so Mike Muss did his usual thing and suggested he could put UNIX on it (he had done this twice previously with orphaned machines: some 11/34 graphics stations that were supposed to be connected to the CDC7600 and converting the University of Illinois Arpanet Terminal Server (ANTS) to a host that could support long leaders. I was part of Mike’s team. We split up various aspects of the project. Mike ported PCC. I ported ld, and F77 (as we figured the “scientists” would probably want that). Mike did the core of the kernel. I handled all the I/O system because I was the “device driver” guy at JHU and continued on with this at BRL. Our initial work was done by traveling out to Denelcor’s facility where our machine was assembled on their floor. They had started their operating system work (not UNIX), so we took the machine after hours. Amusingly, at BRL in the room the HEP was going in, the cabinet layout was taped out on the floor around a central pillar. The tape marked with the component that went there. Out in the Denver machine room, the equipment was there but there was a square taped out that said “BRL post” so they knew not to put/route anything there. The software being ported was 4BSD. I believe we started with the George Gobels mods of the dual VAX (BRL already had built one of these). In working on that I found there was a rather serious portability problem. The kernel did what I refer to as “conversion by union” where they stuck a pointer of one type into one element of the union and retrieved it by a different pointer type union element. Well, such is all well and good on the VAX, but the HEP encoded the partial word size into the low order bits of the pointer. This meant that you ended up with pointers that would access the wrong size operand. I spent a few days chasing down all these things and fixing them. The HEP had an 11/34 as a control processor that allowed you to configure the switch system that interconnected the memory in the processors. It did this via a special feature called (aptly) “The Low Speed Bus” (more on that later). But once running, everything was self contained on the HEP hardware itself. Other amusing things about the HEP is it had a lot of registers. It also had this stuff called “table memory” which essentially were read-only registers. You could but a variety of constants there (we had all the integers from 0-255 and then powers of two after that). The rest of the memory had an extra bit per 64-bit word called the “full empty” bit. While the thing was capable of running the equivalent of 32 UNIX processes simultaneously, it also had the ability within each of those to hardware schedule threads. Many instructions had features that used the extra bit like “WAIT FULL, READ, SET EMPTY” or “WRITE, SET FULL”. The whole thing was built out of Motorola 10800 ECL. All hand assembled. Quite impressive. After we got the system up, and Mike tried to port his ray tracing software to it, we found the I/O system was beastly slow. The I/O system was a cute device. It had a bunch traditional memory (no full/empty bits) connected to the main memory via the switch but also to 32 individual UNIBUSes. The only problem was that in order to whack the registers on the UNIBUS you had to do it through the “Low Speed Bus.” This was the performance bottleneck. The original designer of this thing, Burton Smith and I sat down at the Golden Corral Steakhouse in Aberdeen and worked on a new plan. The key was to allow the kernel tasks to talk directly to the UNIBUS registers via the regular memory switch. Fortunately, we had an extra switch node in spare parts. We did however need software and another PDP-11 to control the thing. Fortunately, I had spares from my building of the early internet router: BRL-GATEWAY. I also used the little OS on it (LOS) to write the control software. In a couple of days, we had rebuilt the I/O system out of essentially spare parts and it flew. Amusingly, this was the first of two UNIX ports I worked on that didn’t use the standard ISR thing that most of the kernels those days did. After the device driver on the HEP had started the IO up, that thread just ended. When the UNIBUS interrupt came in, a new thread was created to service it. I later did a similar strategy with the message passing coprocessor on the Multibus II. This was a fun waste of about a year. By the time we got this ready for prime time, the Army had decided they didn’t have any supercomputers (other than HEP) and immediately used defense priority to snag the next Cray X/MP off the assembly line (which had been slated for Apple). Mike got one run of his raytracer to make a movie: The artillery shell’s view of collision with a tank. The HEP could generate the frames about 60:1 (took a minute to make one second of movie time) faster than anything else we had in the day. Of course, it pales compared to your modern video games. After that, the HEP was dismantled (Denelcor had gone out of business) to make room for the Cray. I recently just found pictures of us all sitting on the “seats” of the Cray and one of me peering out from the core of the machine. The Army went on for plans for multiple Cray 2 purchases. After a lot of amusing “systems engineering” work that originally slated for all of them to go in Oak Ridge Tennessee, and then all of them to go at BRL, they decided to spread them around the country (what I told them they should do in the first place). My last months at BRL, I signed my name to the $25 million dollar Cray 2 procurement, but it got delivered after I left (I visited it a few years later). Somewhere I still have the name plates for the Denelcor HEP H1000. They, in fact, were never actually installed on the machine,

Bitsavers has some files on the HEP, if anyone is interested. The research papers are a collection of undated, probably published pieces. <http://www.bitsavers.org/pdf/denelcor/> -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

On Sat, Aug 05, 2023 at 04:00:55PM -0700, scj(a)yaccman.com wrote: Was this over NFS? Because that was a thing. Paging in from disc I've never heard of this. BTW, scj, loving your walk through history. I'd love to read drafts of your management book. My entire career I waited to meet a person that got as much joy out of managing as I got out of engineering. Still waiting.

The first foray into multiprocessor UNIX for us was to build one of the Purdue University dual vaxes (where they took the SBI terminator out, built some special cables to flipped around, and to stick a second CPU in that location. Not too much later we got a multiprocessor Gould SEL machine (also with Purdue’s hack to BSD as the OS). BRL had contracted to buy a Denelcor HEP, which was a MIMD machine capable of running 32 or so parallel tasks. Each one could be divided into multiple processes (what we would call a thread the days). The regular memory had a semaphore per word (called a full-empty bit) that allowed you to create a bunch of threads and let the hardware itself schedule them. There were four Process Execution Modules (each with 8 processors) that were interconnected by a fast memory switch, alll 10800 ECL. The thing was booted up from a PDP-11/34 front end through an interface aptly named the “low speed bus”. Mike Muuss suggested we could put UNIX on the thing and nobody could come up with a reason why not, so we ported the same 4 BSD kernel that the dual vaxes were using. Oddly, there were some bad things in the BSD kernel that needed to be fixed (notably “conversion by union” that wouldn’t work on this architecture). After the initial boot up, we found that the thing couldn’t run I/O’s very quickly as they I/Os were routed through the “low speed bus.” The hardware designer (Burton Smith) and me literally designed a new I/O interface on napkins at the local steakhouse, the Golden Corral, and built the thing out of spare parts. I donated another PDP-11/34 to the task. The I/O system was a fun system, the thing had 32 Unibuses connected to a memory cache for the main processor. You could hit the CSRs on the Unibuses virtually through mapped memory addresses. Interrupts weren’t the traditional sense but rather a new kernel task was spawned to handle it. -Ron