TUHS

tuhs@tuhs.org

43 participants
6501 discussions

The death of general purpose computers -> COFF

by Warren Toomey

Hi all, can we move "The death of general purpose computers" to COFF now as it's not directly relevant to Unix. Thanks, Warren

2 years, 4 months

Managers/architects (was: AIX moved into maintainance mode)

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > At least 30 years ago I said "He's good programmer, a good architect, > and a good manager. I've never seen that in one person before". Corby? Although he was just down the hall from me, I never saw him operating in any of those roles; maybe some of the old-time Unix people have some insight. Saltzer is about off-scale in #2; probably good as a manager (although I had a monumental blow-up with him in the hallway on the 5th floor, but I was pretty close to unmanageable when I was young ;-); he took over Athena when it was stumbling, and got it going. Dave Clark is high on all three - he could manage me! :-) Bob Taylor? PARC did some _incredibly_ important stuff in his time. Yes, I know a lot of the credit goes to those under him (Butler Lampson, Alan Kay - not sure if he was in Taylor's group, Boggs, Metcalfe, etc) but he had to manage them all. Not sure what his technical role was, though. Vint Cerf? Again, A1*** as a manager, but had some failings as a architect. I think the biggest share of the blame for the decision to remove the variable size addresses from TCP/IP3, and replace them with 32-bit addresses in TCP/IPv4, goes to him. (Alas, I was down the hall, not in the room, that day; I wasn't allowed in until the _next_ meeting. I like to think that if I'd been there, I could/would have pointed out the 'obvious' superior alternative - 'only length 4 must be supported at this time'.) Noel PS: ISTR that about a month ago someone was asking for management papers from that era (but I was too busy to reply); two good ones are: - F. J. Corbat��, C. T. Clingen, "A Managerial View of the Multics System Development" https://multicians.org/managerial.html - F. J. Corbat��, C. T. Clingen, and J. H. Saltzer, "Multics -- the first seven years" https://multicians.org/f7y.html

2 years, 4 months

Re: Managers/architects (was: AIX moved into maintainance mode)

by Douglas McIlroy

> My guess is that Ivan Sutherland probably qualified back when he still > programmed ... I mean, after all, he invented the linked list in order to > implement his thesis program (Sketchpad) in about 1960. I don't know whether Sutherland invented the linked list, but if he did, it had to be before he worked on sketchpad. I attended a lecture about Lisp in 1959 in which McCarthy credited list-processing to IPL-V, whose roots Newell places in 1954. Sketchpad ran on TX 0, which became operational in 1956. My nomination for a triple-threat computer guy is Vic Vyssotsky. A great programmer, he invented the first stream-processing language (BLODI) and bitwise-parallel dataflow analysis. As an architect, he invented the single underlying address space for multics. As a manager, he oversaw the building of and later ran the lab that became AT&T Research. Finally he founded the DEC Cambridge Lab. He was a subtle diplomat, too, who more than once engineered reversals of policy without ruffling feathers. Relative to linked lists, I remember Vic perceptively touting the then startling usage J=NEXT(J).in Fortran. Doug

2 years, 4 months

Re: AIX moved into maintainance mode (fwd)

by Steve Nickolas

Accidentally sent this only to the person I was replying to. > I am getting some grief on Twitter too for "omitting" FreeBSD. I > didn't, but the BSDs don't fit either definition of "Unix". The > pre-1993 one being "based on AT&T code" -- after all, BSD (4.4 Lite r2 > was it? Before my time!) -- went to a lot of effort to eliminate AT&T > code. From what I've seen it's very much a gradual transition; 4.3-Tahoe starts to have the new code and UCB copyright notices with the predecessor of what we call the "BSD License" appearing in some of the source files. Then with Reno, a majority of the userland is open-sourced, and Net/2 is fairly complete. (Net/2 and 4.4BSD-Lite / Lite/2 were lacking a few things.) But even right up until the end things were in a state of flux. A few things weren't finished until much later by the FreeBSD, OpenBSD and NetBSD people. -uso.

2 years, 4 months

Re: Maintenance mode on AIX

by Joseph J. Mankoski ***PSI***

Hello -- Regarding "appliance-ization" (locking down / dumbing down) of commercially-available computer systems, and returning to the history of Unix (in the context of our current era), I am reminded of Ken Thompson's (excellent and humorous) panel presentation at the ACM Turing 100 conference I attended in 2012, imagining Alan Turing being brought to our time and given a current-generation computer system, etc. The webcast links for the "Systems Architecture" session, etc., on the main conference site, https://turing100.acm.org/, seem to be broken, however the video at this link works for me: https://dl.acm.org/doi/10.1145/2322176.2322182 (Ken's part starts at ~0:09:28.) Cheers, ***PSI*** <<<psi(a)valis.com>>> tuhs-request(a)tuhs.org writes: [...] > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 18 Jan 2023 17:08:00 +0000 > From: segaloco <segaloco(a)protonmail.com> > Subject: [TUHS] Re: Maintenance mode on AIX > To: Clem Cole <clemc(a)ccc.com> > Cc: tuhs(a)tuhs.org > Message-ID: <zpdIicuX7AbN-y6hYho0eLOnHgzRs4iHa1UD6bxUyiTZhqZkg3Ha8TKWV > ASxWkDZitFw0JIopRVh7BRC2PzLFrF_Gjsb2yCi-uxJ3Yr3AtE=(a)protonmail.com> > Content-Type: multipart/alternative; > boundary="b1_7WKJsCnT0P2jggZLBLwbL2iRavDFXPykjXdIMPRs" > > Apple's unreasonable hardening has been the latest deterent to my ever wanting to use macOS as a personal driver. I've got a Mac as my daily driver for work, it can happily stay with work until I can decide how the filesystem is laid out and what folders I, as the root user, can and can't interact with from user land. I own my machine, not Apple. > > - Matt G. > ------- Original Message ------- > On Wednesday, January 18th, 2023 at 8:59 AM, Clem Cole <clemc(a)ccc.com> wrote: > >> On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy <lm(a)mcvoy.com> wrote: >> >>> Someone once told me that if they had physical access to a Unix box, they >>> would get root. That has been true forever and it's even more true today, >>> pull the root disk, mount it on Linux, drop your ssh keys in there or add >>> a no password root or setuid a shell, whatever, if you can put your hands >>> on it, you can get in. >> >> A reasonable point, but I think it really depends on the UNIX implementation I suspect. Current mac OS is pretty well hardened from this, with their current enclaves and needing to boot home to Apple to get keys if things are not 100% right. Not saying you or I can not, but basically means the same cracking tricks you need to use for iPhones. It's not as easy as you describe. >> >> The ubiquitous Internet/WiFi changed the rules - as you can start to keep some set of keys somewhere else and then encrypt the local volumes. In fact, one of the things they do if mac OS boot detects that root has been modified (it has a crypto index stored away when it was made read-only), the boot rolls back to the last root snapshot -- since they are all read-only that works. In fact, it is a PITA to update/fix things like traditional scripts (for instance the scripts in the /etc/periodic area). Basically, they make it really unnatural to change the root files system, make a new snapshot and index (I have yet to see it documented although, with much pain, I previously created a procedure that is close -- i.e. it once worked on my pre-Ventura Mac - but currently -- fails, so I need to some more investigation when I can bring this back to the top of the importance/curiosity stack (I have a less than satisfying end around for now so I'm ignoring doing it properly). >> >> Clem >> ᐧ

2 years, 4 months

Burroughs funded $30,000 for a port to E-mode stack machine in 1983!

by ron minnich

I just stumbled across an old letter, from a VP of Burroughs to me and Steve Bartels, authorizing $30,000 for a port of Unix to the E-mode stack machine. I had forgotten getting it. Burroughs was famed for its stack machines. E-mode was a kind of last gasp attempt to save the stack architecture, which failed as far as I know, see this table: http://jack.hoa.org/hoajaa/Burr126b.html I worked as a hardware engineer on the A15. I also had been a Unix user for 7 years at that point and kept pointing out how awful the Burroughs CANDE time-sharing system was, and how much better Unix was. At some point I guess they asked me to put up or shut up. I got that money, and left Burroughs a week later for grad school. Funny note: A15 was Motorola ECL (MECL), and ran at 16 Mhz., considered fast at that time. We used a technique called "stored logic" which was, believe it or not, using MECL RAM to map logic inputs to outputs, i.e. implement combinational logic with SRAM. Kind of nuts, but it worked at the time. We also used a precursor of JTAG to scan it in. Those of you who know JTAG have some idea of how fun this had to be. One side effect of working with MECL is you realized just how well designed the TI 7400 SSI/MSI parts were ... MECL always just felt like an awkward family to design with. Another funny story, pointing to what was about to happen to Burroughs. We had an app that ran for hours on the stack machine. We quick ported it to a VAX, started it up, and headed out to lunch -- "this will take a while, let's go eat." We got to the front door and: "Oh, wait, let me hop back into the office,I forgot my jacket". And, noticed, the program was done in ... about 3 minutes. Not 8 hours. That's when we knew it was game over for Burroughs. If a picture of this letter would be useful in some archive somewhere, let me know, I can send it.

2 years, 4 months

In search of SunOS 4-era security advisory.

by Dan Cross

The security vulnerability in question could be briefly summarized as, "Fortran divide-by-zero gives root." I think that was just a specific manifestation of the underlying problem, though. More specifically it was actually due to failure to sanitize state after handling a SIGFPE (and possibly other signals as well?). I have a distinct memory of this, but can no longer find any evidence for it. Did I just make it up from whole cloth, or was this actually a thing? - Dan C.

2 years, 4 months

A few comments on porting the Bourne shell

by Paul Ruizendaal

London and Reiser report about porting the shell that “it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.” By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far. There were three aspects that I found noteworthy: 1. London/Reiser apparently felt strongly about a property of casts. The code argues that casting an l-value should not convert it into a r-value: <quote from "mode.h"> /* the following nonsense is required * because casts turn an Lvalue * into an Rvalue so two cheats * are necessary, one for each context. */ union { int _cheat;}; #define Lcheat(a) ((a)._cheat) #define Rcheat(a) ((int)(a)) <endquote> However, Lcheat is only used in two places (in service.c), to set and to clear a flag in a pointer. Interestingly, the 32V code already replaces one of these instances with a regular r-value cast. So far, I’d never thought about this aspect of casts. I stumbled across it, because the Plan 9 compiler did not accept the Lcheat expansion as valid C. 2. On the history of dup2 The shell code includes the following: <quote from “io.c”> rename(f1,f2) REG INT f1, f2; { #ifdef RES /* research has different sys calls from TS */ IF f1!=f2 THEN dup(f1|DUPFLG, f2); close(f1); IF f2==0 THEN ioset|=1 FI FI #else INT fs; IF f1!=f2 THEN fs = fcntl(f2,1,0); close(f2); fcntl(f1,0,f2); close(f1); IF fs==1 THEN fcntl(f2,2,1) FI IF f2==0 THEN ioset|=1 FI FI #endif } <endquote> I’ve check the 8th edition source, and indeed it supports using DUPFLG to signal to dup() that it really is dup2(). I had earlier wondered why dup2() did not appear in research until 10th edition, but now that is clear. It would seem that the dup of 8th edition is a direct ancestor to dup() in Plan 9. I wonder why this way of doing things never caught on in the other Unices. 3. Halfway to demand paging I stumbled across this one because I had a bug in my signal handling. From early days onwards, Unix supported dynamically growing the stack allocation, which arguably is a first step towards building the mechanisms for demand paging. It appears that the Bourne shell made another step, catching page faults and expanding the data/bss allocation dynamically: <quote from “fault.c”> VOID fault(sig) REG INT sig; { signal(sig, fault); IF sig==MEMF THEN IF setbrk(brkincr) == -1 THEN error(nospace); FI ELIF ... <endquote> This was already present in 7th edition, so it is by no means new in 32V or SysIII -- it had just escaped my attention as a conceptual step in the development of Unix memory handling.

2 years, 4 months

C with Classes reference manual

by Ron Natalie

Here’s a stretch, but does anybody have a copy of the 1982-ish C With Classes Reference Manual kicking around. I can take it in n/troff or a more modern format if you have it.

2 years, 4 months

Re: A few comments on porting the Bourne shell

by Douglas McIlroy

> segaloco via TUHS writes: >> I think that's a good point that scripting problems may be >> a symptom of the nature of the tools being used in them. > I think that you're hinting at something different. > To the best of my recollection, scripting languages were originally > intended and used for the automation of repetitive personal tasks; > making it easier for users who found themselves typing the same > stuff over and over again. Indeed! > Somewhere along the line people forgot > how to use a compiler and began writing large systems in a variety > of roughly equivalent but incompatible interpreted languages. Can > one even boot linux without having several different incompatible > versions of Python installed today? So I don't think that it's the > nature of the tools; I think that it's people choosing the wrong > tools for the problems that they're trying to solve. > Jon The forgotten compilers were typically used to supply glue to paste major tools together. The nature of that glue---often simple data reformatting--inspired tools like sed and awk. Each use of a tool became a process that saved many minutes of work that would in a scriptless world be guided by hand, boringly and unreliably. Yet glue processes typically did only microseconds of "real" work. In the name of efficiency, the operations began to be incorporated directly into the shell. The first inklings of this can be seen in "echo" and various forms of variable-substitution making their way into the v7 shell. The phenomenon proliferated into putting what were typically canned sed one-liners (but not sed itself) into the shell. Lots of specializations crowded out universality. A side effect was an explosion of knowledge required to write or understand code. Such is the tragedy of "forgetting compilers". Doug

2 years, 4 months

Unix documents on github.

by Dan Cross

Someone dumped a bunch of Unix/Plan 9/FORTRAN/FOCAL documents on github: https://github.com/kenmartin-unix/UnixDocs I haven't looked at them closely to see what may be there, but this may interest some TUHS readers. - Dan C.

2 years, 4 months

Re: AT&T UNIX PC (7300) Teardown and Restoration

by segaloco

I'd love to get my hands on a 3B2 someday, this'll be cool if I can get it going but that'd be a much more robust machine. I'm starting to suspect if there isn't any sort of boot ROM that spits out commentary on the UART and that doesn't get flexed until UNIX is up, I may not be able to get very far. I referred to http://bitsavers.trailing-edge.com/pdf/att/3b1/999-809-010IS_UNIX_PC_Remote… for the serial settings and it appears: 9600 baud, 1 stop bit, no parity, 8 data bits And the relevant pins Pin 1 - GND Pin 2 - RX Pin 3 - TX Pin 4 - RTS Pin 5 - CTS Pin 6 - DSR Pin 7 - GND Pin 8 - DCD Pin 20 - DTR So I've plugged my USB-TTY GND/RX/TX into the relevant pins and setup the necessary tty settings. The manual then suggests if running null modem mode to short pin 4 to 5 and then pins 6, 8, and 20 together, presumably omitting any need for modem signalling from the remote machine, doing basic serial RX/TX. Unfortunately even with all of this bypassing I get nothing out of the RS-232 port. What I don't know is if I could even expect something or if this is unlikely to bear fruit whether the hardware works or not. In any case, if I do get this thing running I'll have a writeup for folks afterwards. If not, then hopefully I can figure out something useful to do with this thing rather than junking it. - Matt G. ------- Original Message ------- On Tuesday, January 3rd, 2023 at 3:53 PM, rob(a)atvetsystems.com <rob(a)atvetsystems.com> wrote: > Hello Matt, > > I’ve got one of these in my garage. I bought it about twenty years ago as a working system but when I got it home I noticed that the hard disk wasn’t connected but at some point I’d like to get it and my 3b2/300 working. > > Regards, Rob. > >> On 3 Jan 2023, at 23:27, segaloco via TUHS <tuhs(a)tuhs.org> wrote: >> >> And here are some pictures of the guts. >> >> https://imgur.com/a/E1ioxZl >> >> Various bits inside date this to late 1985. The good news is it at least turns on, but that's about as far as I've gotten with it. The display never turns on, nor do I hear any sounds indicating it tries to start the CRT. The fans kick on and there it stays until I turn it off. I plugged in a USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 stop no parity and got nothing. Swapped the RX/TX, still nothing. Of course, that's all predicated on the assumption there's something there to even interact with. I have little faith that whatever UNIX install was on this is extant. Additionally, it didn't come with a keyboard, so if there was some futzing with key combos that would trigger some sort of UART over those lines, I can't do that. I wonder if there are some contacts inside I can just poll for activity with this serial connector, not sure how safe that is... >> >> Anywho, the CPU has a bit of corrosion on the surface, not sure how that bodes for the innards, but this is in kinda rough shape either way. I hope I can salvage it but if not, I'm going to at least do some study on the CRT particulars and see if I can extract and keep the monitor from it, been wanting a smaller CRT to have around for a while. >> >> - Matt G. >> ------- Original Message ------- >> On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS <tuhs(a)tuhs.org> wrote: >> >>> Good day everyone, just starting a thread for yet another project I'll be tinkering on over time. Picked up a (presumably broken/untested) 7300 off eBay to at the very least tear down and get some good pictures of and, with some luck, perhaps get working again. >>> >>> https://imgur.com/a/CExzebl >>> >>> Here are some pictures of the exterior for starters. I'll update this thread when I've got pictures of the guts and also with any info I can glean regarding whether this might be salvageable. The rust on the back is pretty nasty but I've seen older/worse start up just fine. >>> >>> - Matt G.

2 years, 4 months

AT&T UNIX PC (7300) Teardown and Restoration

by segaloco

Good day everyone, just starting a thread for yet another project I'll be tinkering on over time. Picked up a (presumably broken/untested) 7300 off eBay to at the very least tear down and get some good pictures of and, with some luck, perhaps get working again. https://imgur.com/a/CExzebl Here are some pictures of the exterior for starters. I'll update this thread when I've got pictures of the guts and also with any info I can glean regarding whether this might be salvageable. The rust on the back is pretty nasty but I've seen older/worse start up just fine. - Matt G.

2 years, 4 months

C Style and Coding Standards for SunOS

by Dan Cross

Does anyone have the original troff of this document? It was written by Bill Shannon at Sun, documenting the C style conventions for SunOS. A PDF rendering is here: https://www.cis.upenn.edu/~lee/06cse480/data/cstyle.ms.pdf Thanks! - Dan C.

2 years, 4 months

Interview question

by Larry McVoy

The /bin/sh stuff made me think of an interview question I had for engineers, that a surprisingly few could pass: "Tell me about something you wrote that was entirely you, the docs, the tests, the source, the installer, everything. It doesn't have to be a big thing, but it has to have been successfully used by at least 10 people who had no contact with you (other than to say thanks)." Most people fail this. I think the people who pass might look positively on the v7 sh stuff. But who knows?

2 years, 4 months

Porting the SysIII kernel: boot, config & device drivers

by Paul Ruizendaal

As mentioned in the first post on SysIII porting, I was surprised to see how much code was needed to initialise modern hardware and to load an OS. Of course, modern devices are much more capable than the ones of 40 years ago, so maybe my surprise is misplaced. It did raise an interest in the history of Unix system configuration though. It would seem that 5th Edition already contained a configuration program that generated a few system tables and the ‘low.s’ file with interrupt vectors and alike. Although it steadily grew in sophistication, the approach appears still the same in SysIII. I suppose this is all in line with common practice of the era, with OS’s typically having a ’system generation kit' to combine the pre-linked OS kernel with device drivers and system tables. SysIII also introduces the "var struct" and the “v” kernel variable that summarises some of the system configuration. I’m not sure whether it has roots in earlier Unix systems, it does not seem to originate from Research. I’m not sure what the point of this ‘v’ kernel variable was. Does anybody remember? One could argue that one of the drivers of the success of CP/M in the 1970’s was due to its clear separation between the boot rom, BIOS and BDOS components. As far as I am aware, Unix prior to 1985 did never attempt to separate the device drivers from the other kernel code. I am not very familiar with early Xenix, it could be that Microsoft had both the skill and the interest to separate Xenix in a standard binary (i.e. BDOS part) and a device driver binary (i.e. BIOS part). Maybe the differences in MMU for the machines of the early 80’s were such that a standard binary could not be done anyway and separating out the device drivers would serve no purpose. Once the PC became dominant, maybe the point became moot for MS. It would seem that the next step for Unix in the area of boot, config and device drivers came with Sun’s OpenBoot in 1988 or so. This also appears to be the first appearance of device trees to describe the hardware to the bios and the kernel. Moreover, it would seem to me that OpenBoot is a spiritual ancestor of the modern Risc-V SBI specification. Maybe by 1988 the IO hardware had become sufficiently complex and/or diverse to warrant a break from tradition? Was there any other notable Unix work on better organising the boot process and the device drivers prior to OpenBoot?

2 years, 4 months

Re: A few comments on porting the Bourne shell

by Douglas McIlroy

> "Originally the idea of adding command line editing to ksh was > rejected in the hope that line editing would move into the terminal > driver." [2] > I have always wondered, what such a central terminal driver driven > history/line-editing would have felt like. You can get a feel for it in Rob's "sam" editor, which works that way. Doug

2 years, 4 months

Re: plan9 compiler memory use

by Steve Simon

at the risk of making a fool of myself - there are several people far better qualified here, however… my memory is that the plan9 linker could be easily rebuilt to use malloc and free in the traditional style, reducing its memory footprint - though making it much slower. -Steve

2 years, 4 months

Early Unix on (64-bit) Risc-V

by Paul Ruizendaal

Adam Thorton wrote: > I mean all I really want for Christmas is a 64-bit v7 with TCP/IP support, a screen editor, and SMP support. > > The third one is a solved problem. The second one would not be that hard to adapt, say, uIP 0.9, to v7. That first one would require some work with C type sizes, but getting larger is easier than the reverse. It's that last one. > > Having said that...maybe what I really want is 64-bit 4.3 BSD? > > I mean, just a Unix, without all the cruft of a modern Linux, but which can actually take advantage of the resources of a modern machine. I don't care about a desktop, or even a graphical environment, I don't care about all the strange syscalls that are there to support particular databases, I don't care much about being a virtualization host. Luther Johnson wrote: > I'm in the process of building a system like that for myself, but > perhaps a little smaller - mine will be based on an embedded > microprocessor I've developed (so much work still yet to do ! at least a > year out). Earlier this year I ported VAX System III to Risc-V, to a simple Allwinner D1 based SBC. This is RV64GC. Just ported to the console terminal. It turned out that porting Sys III to 64 bit was surprisingly easy, most of the kernel and user land appears to be 64 bit clean. It helps that I am using a LLP64 compiler, though. Apart from networking Sys III also feels surprisingly modern (for an ancient Unix) - its should get more attention than it does. The hardest work was in porting the VAX memory code to Risc-V page tables (and to a lesser extent, updating libc for the different FP formats). The code is currently in an ugly state (with debug stuff in commented-out blocks, a mix of ansi and K&R styles, an incoherent kludgy build system, etc.) and the shame stopped me from putting it out on gitlab until I found enough time to clean this up. As there seems to be some interest now, I’ll put it up anyway in the next week or so. There you go Adam, half your wish comes true. The kernel is about 60KB and most binaries are quite close in size to the VAX equivalents. My next goals for it are to re-implement the Reiser demand paging (I think I have a good enough view of how that worked, but the proof of the pudding will be in the eating), and to add TCP/IP networking, probably the BBN stack. Making it work on RV32 and exploring early SMP work is also on my interest list. === David Arnold wrote: > I think xv6 does SMP? (param.h says NCPU = 8, at least). > > You’d need to add a network stack and a userland, but there are options for those … For the above, making xv6 work on the D1 board was my first stepping stone, to proof the tool chain and to get the basics right (hardware init, low-level I/O, etc.). As an educational tool, I am sure that xv6 hits all the right spots, and it certainly does SMP (the D1 is single hart, so I have not tried that myself). I like it a lot in that context. However, as a simple Unix it is useless: from a user-land view it is less capable than LSX. At minimum it needs fixes to make the file system less constrained. In my view, for SMP Keith Kelleman’s work for Sys-V is probably a better place to start.

2 years, 4 months

Xv6, Linux and SysIII on a RV32 FPGA system

by Paul Ruizendaal

Having done the SysIII 64-bit port to a recent Risc-V chip, I realised that whilst it is an interesting exercise bij itself -- and maybe even useful to students and educators around the world -- it is not ideal as a research tool for analysing Unix from the early 80’s. The address size difference adds some superfluous porting, and the 100x speed difference can hide critical algorithm constraints. Also the complex IO devices are out of character. For a Risc-V 32 bit target I’ve settled on an FPGA implementation from the University of Tokyo. I’ve somewhat modified the system to work with the open source Yosys/NextPNR tool chain. It now implements a Linux-capable SoC with a full MMU, a 4-way cache and SD card driver in less than 4,000 lines of plain Verilog (compiling to about 14K LUTs). In a way, the code has a 6th edition feel to it: it covers a real and usable system and the code can be understood in a couple of days -- or a semester for a student who is new to the concepts involved. https://gitlab.com/r1809/rvsoc/-/tree/main/doc So far I have Linux and XV6 (https://gitlab.com/r1809/xv6-rv32) running, but have not started on SysIII yet. Usefully for my use case this system is not very fast, completing an instruction in on average 10 clocks. Still, when running at 40MHz it is about 2 or 3 times as fast as a VAX11/780, which is similar to the systems of the mid-80’s. Even at this speed, a single user console Linux is surprisingly usable. By the way, funny to realise that ‘Unix/Linux capable’ has been a marketing slogan for system capability for 40 years now. There is a short video clip with a demonstration (but running at 100MHz) here: https://youtu.be/Kt_iXVAjXcQ Due to its simple design, the main CPU only uses some 30% of the cache memory bandwidth and it should not be all that hard to add a second CPU to the system (the CPU already supports the Risc-V atomic operations), and this could be a nice target for studying the early Unix multi-processor designs (e.g. VAX/BSD & 3B2/SVR3). I find it an intriguing thought that the chip technology of the early 80’s (let’s say the technology used for the Bellmac-32 or M68K) would probably have sufficed to build a CPU similar to the one used in this FPGA design. As the topic of this post is on a tangent from the focus of this list, I would recommend that any follow-ups not related to the history of Unix are sent off list.

2 years, 4 months

Porting the SysIII kernel: first steps & memory management

by Paul Ruizendaal

Porting the SysIII kernel to a D1 board (https://www.aliexpress.us/item/3256803408560538.html) began with a port of XV6, in order to test the tool chain and to get comfortable with this target. Michael Engel had already ported XV6 to the D1 chip a few months before (https://www.uni-bamberg.de/fileadmin/sysnap/slides/xv6-riscv.pdf) giving a ready base to work with. The main new effort was to add code to initialise the DRAM controller and the SD Card interface, and to have a simple boot loader. Such code is available from the manufacturer board support package (BSP), although in this case the DRAM controller code was only available as assembler compiler output and had to be reverse engineered back into C. In general I was surprised to see how big and unwieldy the BSP code is; maybe the code just looks sloppy because it has to deal with all kinds of edge cases - but I can also imagine that it accumulates cruft as it is ported from SoC to SoC by the manufacturer. The resulting XV6 source tree is here: https://gitlab.com/pnru/xv6-d1 This version automatically boots from the SD Card on the board. With that out of the way, the ancient Unix port was relatively easy. It would seem to me that the SysIII code base has a lot of clean-up work in it that still pays off today. The code compiles to a 64-bit target with minimal updates, which I think is a compliment to the engineers that worked on it. Probably using a LLP64 compiler also helped. In order to bring something up quickly, I modified the kernel to load ELF binaries, so that I could use proven material from the XV6 port (such as a minimalistic init and shell). Initially, I just replaced VAX memory management with page table code taken from XV6 (i.e. no VM or swapping). Working with Risc-V page tables gives much simpler code, but I have a deeper appreciation of the VAX paging design now: for the type of code that was run in 1980, the VAX design enables very small page tables with just a few dozen entries. In contrast, for the 3-level page tables of 64-bit Risc-V I end up with 7 pages of page table of 4KB each, or 28KB -- that is larger than the memory image of many SysIII programs. If I move the ‘trampoline' to just above the stack in virtual memory it could be 5 pages instead of 7, but the overall picture remains the same. The 68020 or ‘030 MMU could be configured to have various page sizes -- this looked byzantine to me when I first saw it, but it makes more sense now. Next I replaced the VAX scatter paging / partial swapping code, keeping the same methodology. I noticed that there is still confusion over memory management in 32V and SysIII (and implicitly SVR1,R2). The original 32V as described in the London/Reiser paper used V7 style swapping. This code can be found as ‘slowsys’ in the surviving source (https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/slowsys) It was quickly (Mar vs. Jan 1979) replaced by the scatter loading / partial swapping design already hinted at in the paper (source is in 32V/usr/src/sys). Unfortunately, the “32V uses V7 swapping” meme lives on. In scatter paging, the pages are no longer allocated continuous in physical memory but new pages are taken from a free list and expansion swaps are not usually needed. Also, when a process is swapped out, it is not fully swapped out, but just enough pages to make room for the new process. When it is readied to run again, only the partial set needs to be reloaded. In the VAX context, scatter paging and partial swapping are quite effective and I think competitive with demand paging for the 25-100KB processes that were in use at the time. As I mentioned in the post on the toolchain, the Plan 9 C compiler can easily use 1MB of memory and in a 4MB of core context, this trashes the algorithm; it starts to behave much like traditional swapping. The reason for this is that the entire process must be in memory in order to be able to run and the algorithm cannot recognise that a much smaller working set is needed. The implicit assumption of small processes can also be seen in the choice to limit partial swaps to 4KB per iteration (8 VAX pages). For handling processes with a large memory footprint but a small working set a true demand paged VM approach is needed. The simplest such approach appears to be Richard Miller’s work for SVR1 (see June 1984 Usenix conference proceedings, "A Demand Paging Virtual Memory Manager for System V"). This is a very light touch implementation of demand paging and it seems that enough bits and pieces survive to recreate it. The journey through the memory code made it clear again that in SysIII and before, the memory code is scattered over several locations and not so easy to fathom at first glance. It would seem that in SysV/68 an attempt was made to organise the code into separate files and with a more defined API. It does not seem to have carried through. Maybe this was because the MMU’s of the 1980-1985 era were all too different to be efficiently abstracted into a single framework. Beyond SysV/68, were there any other attempts in the early 80’s to organise and abstract the kernel memory management code (outside BSD)?

2 years, 4 months

Riscv, Plan-9 and a toolchain

by Paul Ruizendaal

After initially gearing up to use the Motorola 68020 or 68030 as a porting target for a study of Unix in the 1980-1985 era, I reconsidered and used Risc-V as a target instead. As the original RISC and MIPS projects were contemporaneous with early 32-bit Unix (32V, BSD, SysIII and SVr1,r2) it seems appropriate and there is currently considerable interest (hype?) around Risc-V. From a programming perspective, the Risk-V ISA does not feel (at least to me) all that different from what was current in the early 80’s — the number of WTFs/min is low. The modularity is a pleasant surprise, as is the observation that the 32-bit and 64-bit instruction sets are almost identical and that compressed instructions mingle nicely with full size ones. The MMU design appears straightforward. Maybe this is because the ISA is still relatively new and has not acquired much historical baggage at this point in its lifespan, but it also seems to be a good synthesis of insights gained over the last 4 decades and applied with a sense of minimalism. At first I was thinking to create a toolchain based on pcc or pcc2 for the SysIII porting effort, based on some preparation I had done when I was still thinking about 68030 as a target (the surviving Blit code includes a pcc-based 68000 compiler and the SysV/68 source archive contains a pcc2-based compiler). Before I got underway with that, I came across a presentation Richard Miller had done about his Risc-V compiler: https://riscv.org/news/2020/10/a-plan-9-c-compiler-for-rv32gc-and-rv64gc/ Richard was kind enough to share the source code for his Risc-V back-end. The first complication was that the source code assumes that it will be running inside a Plan-9 environment, whereas I was looking for a Unix/Posix environment. Luckily somebody already had assembled the libraries needed for this: https://github.com/aryx/fork-kencc I’m not sure where it came from, but I would assume it has some roots in the "Plan-9 from user space" effort. From this work I extracted the minimum needed to get the C compiler working and to build from scratch. The libraries mostly just worked. The compiler was a bit harder: the source code assumes a LLP64 model in a few places and compiling this with clang (which uses a LP64 model) introduces issues in a handful of places. Other than this initial hurdle, the compiler and tools have worked flawlessly, both for 64-bit code and for 32-bit code, and have been a joy to use. One particular nicety is that Plan 9 style "abstract assembler" source for 64-bit code is even more identical to its 32-bit variant than with the mainstream Risc-V assembler syntax. My repo for the tool chain is here: https://gitlab.com/pnru/riscv-kencc Initially, my expectation was that I could only use these compilers as cross-compilers and that I would need to do a pcc2 version for native compilation at some point. However, when I saw how small and fast the tools were, I experimented with using them on SysIII. Much to my surprise the effort required was absolutely minimal, all that was needed was adding a dozen simple standard functions in libc (see here: https://gitlab.com/pnru/SysIII_rv64/-/tree/master/libc/compat) and adding the ‘dup2' sys call. I had not expected that SysIII was so close to the Unix systems of the 1990’s in this regard. This result inspires ideas for future projects: as I plan to add an 8th edition style file system switch anyway, maybe it will not be all that hard to make the Plan-9 debugger work on this “SysIII+” as well. Another observation has been that the code size of binaries compiled for Risc-V by this tool chain is almost the same as those compiled for the VAX by pcc (the Risc-V ones are maybe 10-20% larger). This is using the compressed instructions where possible. This is I think another indication that both the Risc-V ISA and the tool chain are quite well done. The one less positive surprise has been the memory use of the compiler. Even on a relatively simple program file it will quickly use 1 megabyte or more of ram. I understood from Richard that this is because the compiler only malloc()’s and never free()’s by design. This has been a mixed blessing. Such large memory images don’t work all that well with the "scatter paging + partial swapping" memory management of SysIII when memory is constrained to say 4MB of core to mimic the systems of the era. On the other hand, parallel compiling the kernel on SysIII itself heavily exercises the partial swapping code and has been a great test case for debugging. Many thanks to Ken, Rob, Richard and all the others who created this fine tool chain!

2 years, 4 months

Re: Center 127 directory from 6/17/77

by Douglas McIlroy

> James Johnston: >> Yeah, but Rob, where was Fred? I was there in Acoustics Research (not >> 127!) then, using R70 for UCDS. > Rob Pike: > Not in (1)127 yet. He was transferred in some time after I arrived. Not > sure quite when. Mid-80s maybe. > ===== > Early-to-mid 1980s. ftg was already there when I interviewed in early 1984. > Norman Wilson In 1980 Fred was a stalwart of the computer center. There he exhibited great creativity, including the invention of "quest" for sniffing out security lapses throughout the BTL computer network. His findings underpinned the headline claim of the Labs' first computer-security task force (1982), "It is easy and not very risky to pilfer data from Bell Labs computers". Doug

2 years, 4 months

Center 127 directory from 6/17/77

by Tom Lyon

More grist from the scanner.

2 years, 4 months

Re: Center 127 directory from 6/17/77

by Norman Wilson

James Johnston: > Yeah, but Rob, where was Fred? I was there in Acoustics Research (not > 127!) then, using R70 for UCDS. Rob Pike: Not in (1)127 yet. He was transferred in some time after I arrived. Not sure quite when. Mid-80s maybe. ===== Early-to-mid 1980s. ftg was already there when I interviewed in early 1984. Norman Wilson Toronto ON

2 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS