Peter Seibel - Coders at Work - Reflections on the craft of programming

Thompson:I think MIT has always had an inferiority complex over Unix. I gave a Unix talk at MIT and I was introduced by Michael Dertouzos, I think. He expounded on why Unix wasn’t written at MIT and why it should have been. Why they had the opportunity, they had the people, they had everything, and why it wasn’t done there. And it dawned on me that there was a rivalry in their minds. Not in my mind at that point. We did Unix and they did MULTICS, which was this monster. This was just clearly the second-system syndrome.

Seibel:Where MULTICS was the second system after the MIT’s Compatible Time-Sharing System?

Thompson:Yes. So overdesigned and overbuilt and over everything. It was close to unusable. They still claim it’s a monstrous success, but it just clearly wasn’t.

Seibel:My understanding was that a lot of the MIT hackers viewed MULTICS that same way. They preferred ITS and the Lisp-based systems that they built. It seems there was a real fork post-MULTICS. Unix came out, as you well know, and at MIT these Lisp guys went off and did their things on PDP-10s and built Lisp-based systems which, eventually I guess, begat the Lisp machines.

Thompson:Yeah, yeah. I knew all those guys. I thought it was a crazy job. I didn’t think that Lisp was a unique enough language to warrant a machine. And I think I was proved right. All along I said, “You’re crazy.” The PDP-11’s a great Lisp machine. The PDP-10’s a great Lisp machine. There’s no need to build a Lisp machine that’s not faster. There was just no reason to ever build a Lisp machine. It was kind of stupid.

Seibel:Are there any features of MULTICS that you did like but that never made it into Unix?

Thompson:The things that I liked enough to actually take were the hierarchical file system and the shell—a separate process that you can replace with some other process. Before that all systems had some sort of “executive”—that was the typical word for it—which was a built-in processing language. Per-process execution. Every time you type to the shell and it creates a new process and runs whatever you typed and when that dies you come back so that you’re at arm’s length from the thing you’re running.

Seibel:So those are all things you did take; there’s nothing you left behind that you now regret?

Thompson:No.

Seibel:From what I’ve read about the history of Unix, it sounds like you used the design process that you described earlier. You thought about it for a while and then your wife and kid went away for a month and you said, “Oh, great—now I can write the code.”

Thompson:Yeah…. A group of us sat down and talked about a file system. There were about three or four of us. The only person who’s not well known is a guy named Rudd Canady. In those days at Bell Labs the amenities were great—you could call a telephone number and get a transcription. You know, leave a message and say you want it written up and it’ll appear the next day in your inbox as sheets of paper. And Canady, after we talked about the file system on the blackboard for a little while, picked up the phone, called a number, and read the blackboard into the phone.

It came back and it was about as close to a design document as we got except that it had homonyms that you wouldn’t believe. So I went off and implemented this file system, strictly on a PDP-7. At some point I decided that I had to test it. So I wrote some load-generating stuff. But I was having trouble writing programs to drive the file system. You want something interactive.

Seibel:And you just wanted to play around with writing a file system? At that point you weren’t planning to write an OS?

Thompson:No, it was just a file system.

Seibel:So you basically wrote an OS so you’d have a better environment to test your file system.

Thompson:Yes. Halfway through there that I realized it was a real timesharing system. I was writing the shell to drive the file system. And then I was writing a couple other programs that drove the file system. And right about there I said, “All I need is an editor and I’ve got an operating system.”

Seibel:What’s the worst bug you’ve ever had to track down?

Thompson:Basically bugs where memory gets corrupted. It never happens anymore. I don’t know why. But in the early days we were always working with experimental hardware of various sorts, and there’d be some hardware bug.

Seibel:So memory would get corrupted by the hardware screwing up, not by a runaway pointer?

Thompson:It could be pointer. It could be hardware. Or a combination. The one I’m actually thinking of, the worst example, was the on PDP-11. It didn’t have multiply but you could buy a multiply unit and plug it in, but it was an I/O peripheral. You would store a numerator and a denominator and say go. You’d busy-loop and then pull out the answer, the quotient and the remainder. And this thing was built for a non-memory-managed PDP-11 and we got the first experimental hardware for a memory-managed PDP-11 and this multiply unit didn’t fit with the memory management well.

So you’d store into this thing and then you’d busy-test. And during certain aspects of the busy test it would send a physical address down instead of a virtual address and some piece of memory would get clobbered with a numerator of what you were trying to divide by. And it’d be ages before you’d find it, and it’d be different places. That’s by far the hardest one I’d ever had to find.

Seibel:How did you track it down?

Thompson:There was a program that I wrote that was going after a world record for the number of digits of e . Previous world records were limited not by computation—by cycles per second—but by I/O. I came up with a new algorithm where it was computation-bound and I/O became trivial. It was monstrously heavy on multiply and divide. And we noticed that the machine just crumbled whenever I put on my program. And therefore we got the connection.

Seibel:So that gave you the clue that there was a problem with the multiplier; did you ultimately track it down to some root cause?

Thompson:At some point we got it to where you store in the multiplier in the multiply unit, and you pull it back and it wasn’t there. We reported that to DEC and DEC couldn’t find it, and they didn’t want to deal with it. Their normal people didn’t want to deal with this hybrid machine. In those days you actually got the circuit diagrams of the machines, and we actually found the bug in the circuit diagrams. Then we just called DEC and said, “Connect that wire and that wire.”

Seibel:So, thankfully, hardware mostly doesn’t flake out on us that way these days.

Thompson:Yeah. That’s why I think they’re rare. Plus things are isolated from each other more—if you go bizarrely wild you’ll get a fault. Also you did it in assembly language—it’s really easy to have the wrong thing in some register through some subroutine call. When you have a high-level language where the arguments all have to match up, these things become more and more rare.

In the early days, in assembly language, you’d find them a lot. If it was software, as opposed to a combination of software/hardware, usually it would happen in one spot—the same spot would be corrupted. There’d be some correlation of the bug with something. And you could sit there and put a monitor in the operating system. And every so often, or very often, you’d check and see if the error occurred, and stop as quick as you can, and see what’s going on elsewhere, and chase them down that way. So you could attack them.