5-Mar-92 12:28:51,53990;000000000001 Sender: "IN%"AI.CLIVE@MCC.com""@REDGUM Date: 5-Mar-92 12:27:30 From: "Clive Dawson" <"IN%"AI.CLIVE@MCC.com""@REDGUM> To: NOSTALGIA@DEC10 Subject: 36-bit Pioneers Roundtable Mailed-to: nostalgia@qut.edu.au Received: from MCC.COM by qut.edu.au; Wed, 4 Mar 92 06:31 +1000 Date: Tue, 3 Mar 92 14:32:24 CST From: Clive Dawson Subject: 36-bit Pioneers Roundtable To: nostalgia@qut.edu.au Message-id: <12762442847.16.AI.CLIVE@MCC.COM> X-Envelope-to: nostalgia%dec10 In the Fall of 1984, we celebrated the 20th anniversary of 36-bit machines at the Anaheim DECUS Symposium. One of the sessions I chaired was the 36-bit Pioneers Roundtable. Many good stories and anecdotes were traded, as you will be able to tell from the transcript, enclosed below. Enjoy, Clive Dawson ----------------------------------------------------------------------------- 36-BIT PIONEERS' ROUND TABLE Clive B. Dawson MCC Austin, Texas ABSTRACT This was the keynote session of the 36-Bit 20th Anniversary celebration. A select panel of people who played a significant role in the development of the 36-bit family reminisced about the early history of the product line. The following transcript has been edited slightly for purposes of space and clarity. PANELISTS: GORDON BELL -- Vice-Chairman of the Board, Encore Computer Corp. ROBERT CLEMENTS -- Senior Computer Scientist, Bolt Beranek and Newman Inc. JIM FLEMMING -- Consulting Software Engineer, Digital Equipment Corp. RALPH GORIN -- Director, Academic Computer Center, Stanford University RICHARD GREENBLATT -- Vice Pres. and Technical Director, LISP Machine Inc. ALAN KOTOK -- Corporate Consulting Engineer, Digital Equipment Corp. DAN MURPHY -- Senior Consulting Engineer, Digital Equipment Corp. GLENN RICART -- Director, Computer Science Center, University of Maryland TONY WACHS -- Computer Architect, Wang Laboratories, Inc. Clive Dawson: Welcome to the 36-Bit Pioneers' Round Table. We consider this the keynote session of our 20th Anniversary celebration. We have with us a panel of nine people which form a very small subset of the pioneers who are responsible for all of us being here today. I have to begin by saying that one of the hardest tasks I've ever had was selecting the people on this panel out of the dozens, even hundreds, who easily deserve to be called pioneers. I have no apologies other than to say that in some cases the choices were determined simply by who answered their phones. To begin the discussion, I would like to toss out a few questions. For historical purposes, we would like to know: . What it is about the 36-bit architecture that has made these systems stay around for as long as they have? . What do you consider the most important contributions that this architecture has made to computing? . What features of the 36-bit systems do you think will have the largest impact on computing in the 21st century? Page 2 . Who among your co-workers would you most like to have up here with you today? . Which of your personal contributions are you personally proudest of? . You and the other pioneers made history with your contributions to the development of the modern computer. Did it ever feel like you were making history, and did you suspect you'd be talking about it like this, years later? . Finally, it goes without saying that you should feel free to add all of your favorite war stories while answering these questions! Gordon Bell: I think that when people decide that 8 bits aren't enough to store a character set and if they want to go to 9 or some larger number of bits, that is going to extend the life of these systems. Maybe the fact that the 10 is so adapted to handling various character sets is one reason that it will last. Basically, I have one view as a student of computer history which is that the life of a machine will be totally determined by its ability to remember; that is, its brain size or capacity for accessing memory. The degree to which the 30-bit address extensions work well for real problems will have a major effect on how much will be here at the 25th, the 30th, and the 50th anniversaries. I have got to put a plug in here for just the issue of implementing machines. It's conceivable that there will be a new way to implement machines so that we realize they are all software and that we will be able to "compile" machines easily. I think that will be the reason that there will be a 50th anniversary here. The other reason will be Stu Nelson's ability to design machines. When we started out with the PDP-6 initially it was simply just a big PDP-1. We fooled everybody and said it was just a mini. It turned out it was a very big mini and it had an enormous effect on the organization, of course. But the ability to address memory is certainly the thing that determines machine ability and then also the willingness of somebody to implement those architectures. I would draw attention to an exhibit at the Computer Museum by Seymour Cray, clearly the world's greatest computer designer. He says that the best computer designs are done by one individual. So Stu's been at work on designing the Systems Concepts machine and I think he's done an absolutely magnificent job of building another PDP-10; he's got many more 10's after that. So the answer is address space, Stu Nelson, and a silicon compiler are what will determine the longevity of this machine. Dan Murphy: I'd like to say the PDP-10 is a word-oriented machine done right. Back at some point people thought it was important to compact the size of the instruction set and so they were led into byte-oriented order codes. Nowadays that's much, much less important; I think that as people become concerned about the speed of machines they'll be driven back to the word-oriented type of machine and when they look for how to do one of these, the place they'll go to for the most part is a PDP-10. Gordon Bell: And also the PDP-10 is a hard-wired machine -- the first machines actually had a hard wired instruction set. Alan [Kotok] fell into the Page 3 microprogramming abyss in 1972 and still managed to make a fast machine. But if you really want fast machines, you make them simple and you hard-wire their interpreter; that is, you don't put a little machine inside the machine. So the PDP-10 is a good machine to hard wire. Stu cheated a little bit. He did some hard wiring and some microcoding. Alan Kotok: I was trying to think in terms of the original question. I think what got us off on the right foot is that we were in the right place at the right time. We, Gordon and I, and the others who you see in the picture that's around, were obviously in a very small company. At the time we didn't think we knew everything there was to know about computers and we talked to a lot of people. We talked to people at MIT, we talked to John McCarthy, and we talked to a lot of our friends. We thought about LISP and things like that which today, finally after all these years, people are saying are important. Also I want to suggest that the simplicity of the architecture was due to the fact that there were only a few of us and we couldn't build an excessively complicated machine. I think there were only about 700 modules and they only had 3 or 4 gates each. There were incredibly few gates in that machine. The fact that it had some inherent simplicity has helped us all along. The pendulum has swung and now I think it's swinging back towards simplicity as Gordon points out. Dan Murphy: Clive, one of your questions had to do with people here and not here who had a lot to do with the evolution of the machine. I think when you first asked me about this panel I got to thinking of pioneers of one sort or another involved in all this. There's a few that I've come up with that I wanted to pass along a few stories about. I think that its appropriate that we're holding the convention, as we have several times in the past, opposite Disneyland. Because, after all, Walt Disney was one of the pioneers in automation. He, many years before most of us here, was pioneering in film animation, and I submit that what most of us programmers have been doing for many years is trying to make an inert pile of metal act alive and do something useful. As a matter of fact, I think Walt Disney was my childhood hero. He's the only famous person I ever had an autographed picture of. I think you also see it when you look around at how many Mickey Mouse programs we have these days. Another pioneer who I certainly couldn't leave out is Murphy, I don't mean me -- I mean my distant relative who created Murphy's Laws. Now, given the close association over many years, I have been collecting compendiums of Murphy's Laws as they continue to grow because they hold a great many truths and secrets about what we do. As a matter of fact, I have one that I brought along that someone gave me some years ago. There's a couple of things on here I think are particularly appropriate to DEC over the years. This one's called the Murphy Philosophy. It says "Smile! Tomorrow will be worse." There is also the Law of Applied Confusion that I am sure you can relate to: "The one piece the plant forgot to ship is the one that supports 75% of the balance of the shipment." Or in DEC terms: "The part that breaks is probably the cable." Another one which we always say is, "Never time to do it right, Page 4 always time to do it over." And finally, "The first myth of management is that it exists." I'd also like to recognize one other Murphy. As I sat down here and looked around I realized that we don't have any women on this panel. There's one in particular that has been involved with the 6 and the 10 for a long time. I first met her when she was programming the PDP-6 at the MIT AI lab in about 1964 not long after it arrived. I subsequently married her and we've been working together ever since. I'd like Sarah Murphy to stand up and take a bow. [Applause.] I was thinking about the panelists here. Of course, a number of them have been involved in the computer business longer than I have. At one point, I thought John McCarthy might actually be here, and I remember my first acquaintance with John McCarthy was in a computer class that I took as a freshman. This was Introduction to Computers in 1961. We didn't know a whole lot about computers in those days and so we spent 2 or 3 weeks in this course just talking about how to load an AC and things like that. I forget who taught the course, but in any event John McCarthy came in as the guest lecturer one day to talk about LISP. It was quite an experience. He started off and filled the blackboard with CAR's and CDR's and CADADR's and parentheses -- hundreds of parentheses -- and by about 20 minutes into the class everybody was totally confused and the class was literally in a riot. John, of course, looked terribly offended at that. A whole class of obviously ignorant freshmen were unable to understand what he was about. That was my first acquaintance with John McCarthy. I don't remember to this day whether that lecture made any sense or not. Gordon Bell right here on the panel is very well known for unlabeled graphs -- the canonical graph with no labels and no dimensions. I remember one day when we had a customer of some importance into the plant and Gordon was explaining some things. He filled a black board with graphs and curves going up and down like crazy -- never a number on any of them. But that customer was absolutely convinced -- he just sat there in total awe. It was certainly an impressive moment! Alan Kotok: I just wanted to add that I took that computer course when John McCarthy taught it all the time and I even survived. Dan Murphy: There have been a number of changes in DEC over the years. Of course I can't even speak from that much history since I came to work at DEC in late '72 or '73. I started in the Maynard mill. That's where DEC started, and much of the operation was still there in '73. It's a wonderful old building, about 80 years old, next to a mill pond. It's made of brick and wood and is kind of damp. There are lots of bugs and spiders in the buildings, at least there were back then. They were actually quite legendary for that. When I left BBN to go to work for DEC, a couple of people who had been at DEC, Bob Clements and Ted Strollo, gave me a farewell present of a flyswatter and a can of bug spray. Now here it is 11 or 12 years later and DEC has shiny new buildings all around the country. I think Marlboro is an example of a concrete and steel and glass structure and not many spiders at all, Page 5 really. You still get managers remarking on it, "Not many spiders around here anymore..." Gordon Bell: Up in the mill, I recall a sign by the PDP-10 group that had numbered instructions to follow in case of fire. I don't know if it was Kotok or not who added: "0. Call broker." I always think of the 10 group as having their priorities straight and understanding systems! Bob Clements: I can certainly remember the spiders very fondly. I remember the manufacturing technicians and the engineering technicians had a battle one day. One or the other of these groups decided that they had had enough of the spiders. They got appropriate cans of bug spray and cleaned them out of their area which was on one side of a not-all-the-way-to- the-ceiling wall. The other group immediately went out and got their cans of bug spray and decreasing numbers of spiders oscillated back and forth over this wall. At the time I started there, DEC had a total of 500 employees and they didn't occupy the whole mill because Dennison Paper was using a large part of it as a storage area and spiders love that. Every time DEC would go occupy a new space they would have to go chase out all the spiders. Those of us who were there in those days really do remember those spiders very strongly. I'm going to tell another old story. I committed a great breach of DEC security, unintentionally. When we first checked out the KA-10 prototype, our main job was of course to get the timesharing system running and get it ready to sell to people. We did pretty well on that by the way. From the first time we powered on the prototype KA-10 to the time it was actually running the operating system was, as I recall, nine days. And that involved finding all the bad modules and fixing all the logic bugs. Alan Kotok: I don't think that's ever been repeated, and I don't know what we did. Bob Clements: I think we worked pretty hard is what we did! It was fun and I enjoyed it a lot. But one of the next programs I decided to work on was the music program which was mentioned in the trivia quiz with the MK-10. That, of course, came out of the MIT AI Lab, and was written by Pete Samson. It was a fine program that we all enjoyed back in the days when you could take your large 36-bit time sharing machine and make it stand-alone to play music on in the dark of night. So I brought this program up and hooked up the prototype MK-10 and got music out of it, but it didn't seem to be working right. I knew that one of the characteristics of the program was that it watched the power line clock to tune the tones of the program. I had the mistaken impression that it did all the timing from that power line clock. I was getting these strange results and the timing just seemed to be wrong. I figured it was because the PDP-6 made extra memory references it didn't really need, and on the PDP-10 we had solved that, but that might have been affecting the timing problem. Anyway, I called up Project MAC and got Page 6 my friend Greenblatt on the phone. I said, "Greenblatt, I thought that program tuned itself up to the power clock." He said, "Yes it does." And I said, "Why is it running so fast?" He said, "Well, it just tunes the tones -- it doesn't tune the tempo. What does it sound like?" So I held the phone up next to the speaker and started a Bach fugue. And Greenblatt's reply, which I remember to this day, was "Wow, what a fast computer!" So that was a security breach. He shouldn't have known how fast it was at that time. Ralph Gorin: Speaking of music, the PDP-6 that's now on exhibit in the exhibit area last was used seriously for making music. That's appropriate also because Peter Samson was the principal designer of the Samson music box that was attached to that processor. That processor last saw real activity in 1979 when it was part of a triplex system involving a KL, a KA and the PDP-6 itself. So not only do these systems continue to be in use but they seem to hang around. I confess that the PDP-6 seems to be the first computer that I remember the Stanford Computer Science Department actually retiring. We ran out of room. Gordon Bell: There's a reason why that happens -- why that PDP-6 still exists. Every time there's a new PDP-10 it turns out that Stanford trades in the PDP-6 for the next computer. Ralph Gorin: That's not quite true. We only did that once! Gordon Bell: You did it three times! Bob Clements: I claim a point of order and I will tell one war story about that particular PDP-6 and John McCarthy who has been mentioned here and we all know. I was the poor guy who was sent to California with the PDP-6 to install it. John McCarthy had been on the phone to DEC essentially everyday saying, "Where's my computer? Where's my computer?" for a long period of time. We kept saying, "Soon. Soon, John." Finally one day we shipped it. It was quite clear when we got there that he hadn't really expected it. They were in this beautiful round building up in the hills I'm sure many of you have seen. The building was brand new, and did not yet have any air conditioning, and it was August. So we brought this machine in, and after the normal amount of debugging of the PDP-6 on its first installation which took a little while, we got it running. But it never stayed running very long because it was being cooked by the heat that it generated, and the lack of air conditioning, and the sun on the roof. The machine just didn't survive it. We'd fix it, it would run for a while, it would die. It soon became clear that this was going to go on interminably. The regional manager at that time finally came up with a scheme for how to get our money for this computer. He forced me to do the following rather impolite thing: I walked up to John McCarthy and Les Earnest and said, "I've been instructed to tell you that you are Page 7 not meeting the environmental specs for this machine. At any time you have the room at the proper temperature, we will be very glad to come in here and try and make it work. But you can't use it at any other time and we'll just keep trying whenever you have the temperature right." Of course this was impossible for him to accept because he had scheduled a demonstration of this first timesharing system on Stanford campus and his reputation was on the line. Then I continued as instructed, "On the other hand, you could accept the machine and pay for it, at which point I'll be glad to stay around for a while longer and try and make it work. I might even work outside of normal working hours." Since there was only about a day to go before the demo, he and Les went over in the corner, sweated blood for about 30 seconds, came back and signed the acceptance form at a time when the machine didn't even run. So we dutifully kept our part of the bargain, and tried to get this machine running. I have this beautiful image -- my favorite image of John McCarthy: He and Les Earnest went out all over the entire Palo Alto area, found every block of dry ice that could be found, and placed them under the false floor so that the computer would draw up cooled air. Then John went up on the roof in his Bermuda shorts and sprayed the black roof with a water hose to get convection cooling going. We actually got the machine running and did the demo for the computer center people who were dutifully impressed. Everything came off fine. Alan Kotok: I've been making some notes here, keyed by things other people have said, about some of the people who I remember and some of the pioneers. One is Dave Plummer. He joined DEC back in the beginning of the PDP-6 days and was in the development of the operating system for a while. He later became a salesman and I imagine some of you know Dave for his very good presentations. Another Dave is Dave Gross who is still at DEC. He was one of the PDP-10 developers who came in around the time of the KA and worked on the KI. Bob Clements: We've talked about the early hardware. I have a couple of names related to the early software. I think we should add Dit Morse and Tom Hastings as developers of the PDP-6 timesharing system which led to all the rest of them. Gordon Bell: And we ought to remember that we could have a whole session on the first programmer who we carefully didn't invite, I trust. Alan Kotok: Right. Harris Hyman. Gordon Bell: You said it Alan! Harris caused me to learn about mass protest for the first time. The assembler spec had gone out for the machine; we were beginning to run assemblies on the PDP-4 for the 6 and it was the Harris Hyman assembler which caused mass riots. Its features were masked only by the fact that it was so unreliable. Harris played a very important Page 8 part; he had various key pieces in the program. One year we had to ship a machine right at the end of the year -- the famous Brookhaven machine. It was a trivial machine to ship, since it went in the trailer. Bob Clements: With me and my suitcase and guitar! Gordon Bell: (With Bob Clements. There's another little story there.) But as I was saying Harris was building the assembler that sat on the back of the syntax directed compiler that Pete Samson built. But Harris's assembler didn't work and I ended up writing half of it in the last two or three weeks. This was at a time when DEC had $15 million in sales and another million made a real difference -- it was called profit -- at the end of the year. We really had to ship this machine. I said, "Harris, absolutely everything is depending on you getting this Fortran thing done." He'd been working a lot and said, "Ahhh...take it out of my pay!" And there are more, but that's enough. Alan Kotok: Another story about the infamous McCarthy PDP-6 was that when McCarthy was negotiating to buy this machine he told us that LISP was very important to them and that he'd like us to put something into the machine to help LISP operate. And so we talked about that for a while and decided that the appropriate thing to do was to put in a CONS instruction. So, we worked it out and got it into the machine. As I understand it, there was a switch in the LISP system that would enable the use of this instruction since it had to run on other machines. Several years later it was determined that this switch had never been turned on in the Stanford machine! Tony Wachs: You asked about people from the old times and Bob mentioned Dave Plummer. Dave was working there when I started -- except in the summer. Dave had a thing about bugs. The machine that I was working on when I started was up on the top of building 12; I still worked my crazy hours, even then, starting at 3:00 in the morning. There were 27 zillion bugs in there -- one of the things that was standard was a can of bug spray on the console. You could not get Plummer up there. I tried a number of times and couldn't do it. He got back at me, though. For some reason we had moved to a new building and I had an office and he didn't. Given that I started at 3 and went home at noon and he came in at 2 in the afternoon and went till midnight, he asked me if he could share my office. Being the nice person that I am, I let him share my office. I never saw him so it worked out just fine. Then he got promoted to supervisor of the monitor group, and at that point he needed an office with a door. Mine was the only one that had it, so he kicked me out of my office. Most of the crazies were gone when I came there. I heard some interesting stories about Pete Samson and Harris Hyman, of course. There were some real strange people there. Don Whitcraft came along Page 9 after them and cleaned up the code and saw what they had done in patches and made it permanent source code. The only one that was there when I got there was Dick Gruen. Probably a number of you have met Dick -- he's an interesting person. The thing that I remember most about Dick was one morning when I came in at 3 and he had gone home at 2. Absolutely nothing that I had would work anymore and it took me about an hour of debugging to figure out what had happened. Gruen had gotten in there with his soldering gun and changed PUSH to an immediate instruction. Apparently, he did that a lot and most of the time he remembered and unsoldered it before he went home; that time he didn't. Gordon Bell: There's a book I would also like to recommend in which it turns out the PDP-6 is the real hero. It's a very nice book called "Hackers, Heroes of the Computer Revolution", by Steve Levy. In fact, the east coast hackers are going to rendezvous at the museum on Sunday for a book signing. Steve is going to be there. I think its a very excellent book about that era -- the early to mid 60's -- and certainly the PDP-6 is the hero. Bob Clements: I'll comment on that. I was sitting at a meeting of BBN when my pager went off and it said Steve Levy was on the phone. Well, Steve Levy is the president of BBN. So I immediately left the meeting to go take this call, but I suddenly found myself being interviewed for that book. He got my name spelled wrong, and misquoted me somewhat, but that's history. Clive Dawson: If you read this book, I guarantee you'll love it. But you really have to be prepared for when you get to a particular page which mentions the "TICO" text editor. It almost makes you want to throw up. But, except for the typos, I'll second that recommendation. Dan Murphy: Steve obviously doesn't understand the real fundamental philosophy of the hacker, which is that you have to remember and get right the trivial details. You may not know what day it is, but by God, you remember the name of a winning program! Alan Kotok: Which I believe Dan had something to do with. Clive Dawson: One of the people who is featured most prominently in that book -- who in fact has an entire half-chapter devoted to him -- is Richard Greenblatt himself. Maybe this would be a good time for Richard to tell us a little bit about the MIT AI Lab. Many of us don't know too much about this, since they didn't follow the DEC corporate product line that much especially in terms of software. Page 10 Richard Greenblatt: Maybe the best thing would be to talk about some of the early chess-playing escapades. In those days, having a terminal connected to a machine was a lot different than it is now. We had this chess playing program we decided we wanted to play in a human chess tournament. The chess tournaments were located in the scrungy old buildings of downtown Boston, and we had the problem of how to get a model 35 teletype there. What we finally wound up doing was getting a BIG taxi cab -- one of those Checkers with a big trunk in it. We loaded the 35 into the trunk and got it down to Boston. It took 2 people -- we had to wrestle it up to the third floor of the Boylston YMCU which is kind of an old grungy YMCA type building. Stu Nelson was around to hack around with their telephones (we had various telephone hackers). These old guys were all over us because we were messing up their phone lines. They would pick up the line and hear a feep, and this would of course drop our connection. We did it. It was really quite an effort in those days, involving the whole laboratory. We had to have 2 people at the tournament, 2 people at the machine, and a person running back and forth. Each game at a chess tournament is four hours and if you play 5 or 6 rounds over a weekend that's really quite a lot of manpower for a small laboratory to put together and to make that show go. Nowadays, of course, you take the computer with you to the tournament or you just have a portable terminal, so I'm afraid those days are gone forever. But it was a community effort and I think that the people did feel that they were participating in something at the time. I guess another thing that someone suggested I talk about was what kind of an instrument I would have liked on the machine as a tool that I didn't have. The particular one that was brought to mind for me was called the MAR -- Memory Address Register. I had seen it on the TX2 at Lincoln Labs. There was a switch register which you could set up with an address, and if if the machine referenced that memory address it would stop. When we got our PDP-6 we put it on the PDP-6 as an extra hardware mod. Then we proceeded to try to sell it to DEC for a number of years. Everyone at DEC would say, "Gee, this is a great thing, its going to save us lots of time developing a machine." Now my impression -- it may not be what actually happened -- is they said, "That's $10 worth of hardware for those gates and switches and whatever..." Alan Kotok: They probably just didn't fit! Richard Greenblatt: So, it never really made it, at least in the days when I was hacking PDP-10's. Alan Kotok: Sort of like fast divide. There's always something we intended to put in but it never quite makes it. Richard Greenblatt: I don't know how many hours people have spent wondering how some Page 11 variable get clobbered. Something like that would have saved a lot of time. Dan Murphy: Given that TECO has been mentioned in the past couple of minutes together with the difficulties of dealing with old terminals, I thought I might say a little bit about that. Its been fascinating for me for a number of years to see what has happened to TECO. I haven't really had that much to do with it over the years that's its been on the 6 and the 10. As I was going through some of my files, I came across a truly fascinating document here. It's actually a whole set of articles entitled "TECO as a Development Language." One of the articles here is "Structured Programming in TECO" written by Jacquie Stafsudd at Hughes Research Laboratories, Malibu, California. It goes on and on here, with diagrams and examples and so on, all about programming in TECO. This cover memo on the thing was from a well-known manager at DEC who was asking for a report on the possibility of making TECO a standard development language within DEC. They didn't decide to, I think fortunately for us all. A few years before that, of course, a Special Interest Group was started about TECO and this is the first edition of the "Moby Munger" which was the SIG newsletter that Stan Rabinowitz started. It has pages and pages of fun things having to do with TECO and one line hacks you could do with it. TECO has been one of the more popular interactive editors. I don't know if it was the first, but it was certainly one of the better known early ones. That's kind of an example of something that doesn't turn out like you figure it will when you start with it. TECO was never intended to be an interactive editor. The PDP-1, which was of course the predecessor of the PDP-6 by a few years, was where TECO was first written. The PDP-1 had a console terminal, actually an electric typewriter, which was the only terminal connected to it. We prepared the programs off-line on another type of electric typewriter called the Flexowriter which had a paper tape reader and punch. Paper tape was the program storage and I/O medium on the PDP-1. So you sat off line, typed up your program, carried it over to the machine when your machine time was scheduled, and tried to run it. If there were bugs, of course, then it was a case of running back to the Flexowriter and running your original tape through the reader while punching a copy of it, stopping just before whatever it was you wanted to change, and fixing it up. Clearly, this was prone to error. There was an on-line editor called Expensive Typewriter. It was a fairly dumb sort of line-oriented editor, and its name suggests what people thought of it. If you were sitting there editing your program on the PDP-1 you were frowned upon because you were wasting valuable computer time, instead of going off and doing it on the Flexowriter. I wrote TECO originally with the idea in mind that you could go off line to the Flexowriter and type up not your whole program, but just a list of commands that would say how your program would be changed. And you would take that correction tape, along with your original program, to the machine when your time came around, read them both in, and the editor would punch out a corrected version of your program. I designed the TECO command syntax to be so completely obvious and transparent that you could write it in advance and have it correct your program completely without any difficulty. I am sure that those of you who use raw TECO understand how well I succeeded at that! One final thing, of course, is that it lasted in Page 12 that mode for only about a day or two before people immediately realized that what they wanted to do was type in their commands, not off-line on the Flexowriter, but on-line. The PDP-1 had six switches that the program could sense. So I added a feature: If one of the switches was up, instead of reading the command tape, TECO would just wait for commands from the console typewriter. I don't think that switch was ever put down! Richard Greenblatt: The one I remember was the other sense switch. There was a search command, and instead of having a separate N command and S command like real TECO, the difference was reflected in this sense switch. So if you had the sense switch in one position and your search failed, it just typed out an error message and that was all there was to it. In the other position, it punched out your current page on the paper tape punch and then it read in the next page from the paper tape reader and continued the search. To this day I remember sitting there typing along, doing a search for something, all of a sudden hearing that paper tape punch start and saying, "Oh, sh*t!" There was nothing you could do but duplicate the whole paper tape and start all over again. Another story about TECO was that when we got our PDP-6, DEC let us keep our PDP-1 for a while. So we actually used TECO on our PDP-1 as the editor for the PDP-6. Finally, one weekend DEC called said that on Monday morning they would be coming to pick up our PDP-1. This would leave us without any editor at all for the PDP-6. So Nelson and Holloway and I worked 24 hours around the clock for that weekend, and just as DEC was coming to pack up the PDP-1 the following Monday morning we had PDP-6 TECO editing itself enough to just barely stand on its own and serve as an editor. One thing I'll note about that, is that even that early version of TECO had a display. TECO was never ever considered to be usable without a display -- we had a 340 display on it after that first weekend of work. Later TECO made its way to DEC, and was used by I don't know how many people without any display. How they ever managed to live with it, I'll never know. This never happened even a little bit at MIT. TECO was never used even for a day without having a display so you could look at your buffer. Bob Clements: I'll plead a little bit guilty on that -- this is a very incestuous group here. It was during the time that I stayed at Stanford after we agreed to work on their PDP-6 in the evenings that I made the [MIT Project] MAC TECO work on the DEC operating system, having previously used the MAC TECO down at Brookhaven. Glenn Ricart: The 340 display was really a very good idea because you could run programs like BIGSPY that would show you where all the jobs were in memory. If you wanted to see what the performance of your system was you could go in and watch the jobs being shuffled and slotted out to memory and back in again. When you saw a job that was killing the system performance, you would notice what its job number was and go tap that person on the shoulder and say, "Hey, you're the person who's causing us problems. Why don't you come back some other time?" The 340 Page 13 display was only one of the unique hardware features. While today's students sometimes queue for terminals or to wait for a line through a port switch, I remember the days at Case when you would take your DECtape and put it in line on top of the DECtape cabinet. When a DECtape drive came free, the first person whose DECtape was at the far left would get to take down their DECtape and mount it on the drive. That meant that they were able to get on the system. There wasn't really any login -- the critical resource was the number of DECtape drives. Of course, one had to be reserved for the system tape -- how else could you load your programs? So, I remember that you put your DECtape at the end of the line, and if there were too many DECtapes there was a convention that people would move the DECtapes down. If you weren't there when your DECtape was at the front that meant that you missed your turn and the DECtape would go back to the end of the queue. So, this was one of the first queueing systems implemented on a DEC-10 system. All you Galaxy people, read and weep! I think that we should say from the customer's perspective that one of the things that really appealed to people was the idea that a PDP-6 or PDP-10 was so approachable. And I think DEC captured that later in an advertising message that called it the Personal Mainframe. That was really the case because you have to remember that back in the late 60's and early 70's, people thought a big computer was one you loaded card decks into, and which had scheduling boards and operators who would put the right card decks in at the right time to get things through. Or conversely, you might have a PDP-8 which was doing some useful work but on a very small scale. People got very excited when they saw the power of the PDP-8 expanded and multiplied with an approachable, friendly operating system. 36 bits meant that you could divide the word in half and have two pointers in each word, each of 18 bits. As Gordon said, 18 bits was enough to give it a sufficient brain power that it became a fairly interesting machine to work on. It had a number of very friendly instructions and a very consistent instruction set that the programmers found easy to understand and apply rationally. That of course, led to a lot of user-written software which together with the DEC software made it such an obvious machine especially in scientific applications, that it began to see a lot of growth. Of course, DEC has received some of its best software from customers. I don't know that I could or should mention it all, but the Tenex operating system became the basis for TOPS-20. I distinctly remember Erich Knobil's micro/macro scheduler when we were talking about schedulers in those early days. A lot of software came out of the University of Arizona, John Edgecombe, Ed Mulrean, the list goes on and on. Many of them are here in this audience. It was partially that software exchange that made the TOPS-10 system so valuable. We were talking about some of the environmental things like putting water on the roof and ice under the floor. When I was at the National Institutes of Health we didn't have to go to those extremes -- we had natural occurrences that would help us out! One day we turned off the machines and the air conditioning kept going anyway; there was definitely frost in the room by the time we tried to turn the machines back on again. There were supposed to be thermostats but I guess they didn't work. Well, we tried to compensate for that. We were really sorry, and we apologized to DEC for having frozen their machine. A little while later, we did the next best thing we could do. On Friday Page 14 afternoon, the machine was left running unattended over the weekend. The fire department got a call that there was something going wrong in the computer room. They came in with sirens screaming and hooks and ladders, looked around, couldn't find anything wrong, and went home. The rest of us went home too. I later found out that the fire department had come back a little while later. Again, their alarm had gone off, but they couldn't see anything wrong. So they decided the alarm was faulty and shut it off. Well the next point in the story is that Monday morning at 00:01, the DEC customer engineer came to do the preventive maintenance on the machine. When he opened the door he was pushed back by a wall of high-pressure steam. What had happened was that a steam pipe had broken outside and the fire alarm had been set off by a little trail of steam running along the ceiling that no one could see which was setting off the fire sensors. Well, since they turned off the alarm, no one knew that that steam pipe had finally burst and completely saturated the room with high-pressure steam. The DEC CE, knowing exactly what to do in such circumstances, closed the door, called his boss, and said he couldn't do PM that day. The next part of the story comes up at about 7:30 or 8:00. The operator came in and was rebuffed again by a wall of high-pressure steam. He notified the fire department, and it was pretty clear that things were already pretty bad in the room. The steam had, of course, condensed on the ceiling. It was raining in there like a rain forest and there was dirt and debris coming down off the ceiling running through the equipment. We managed to don big hoods that the fire department uses to go through fires to get in to turn off the equipment. It took them about 4 hours to get the valve shut off because a) no one knew where the valve was and b) it had been rusted and corroded shut. It turns out that we ended up saving most of the data -- we actually washed and dried the disk packs and all of the tapes in the room. It took about a week to get the equipment back up, but there is a very golden lining to the story. Having good management on the system we'd been keeping track of the number of system failures per unit time. There would be little peaks and valleys but it had been running along at a constant rate. Right after the steam bath we had almost 6 months of completely error-free performance from our TOPS-10 system. So we've since recommended this to customers who need a highly reliable system! Jim Flemming: People have mentioned names, and Tom Hastings has already been mentioned. You could always tell when Tom was debugging something and he was frustrated because you would come in in the morning and the model 35 would probably be lying upside down, but for sure the glass on top would be broken. That's my only anecdote about people. Actually, you mentioned in the introduction of Ralph the fact that he wrote the simulation for the KA instructions. There were a lot of interesting things that went along with that. As a matter of fact, I recall a comment that said only cretins divide by SETZ. For those of you that don't know what SETZ is, it is the 400000,,0 instruction. In fact, there were some cretins around that divided by SETZ and the simulation didn't hack it very well. So I decided to investigate it. I really didn't know what the right answer was for dividing by SETZ. So I tried it on the KA-10, I tried it on the KI-10, I tried it on the KL-10 and on the KA-10 it generated a number that I later on dubbed Kotok's Constant. The answer on the KL-10 was probably closest to right. It Page 15 actually generated an overflow of some sort and on the KI the answer was 1. So dividing SETZ by SETZ gives you 1. Now in the simulation on Tops-20, it actually just caused your fork to loop. On Tops-10 since we don't reschedule in Exec mode, it caused a keep-alive cease. Tony Wachs: I can't not talk about TECO. I've been at Wang now for a year and a half and they've got plain vanilla editors and...God, I want TECO!! It's the one piece of software I really want. A guy at Wang sent around a questionnaire. He was going to build a new corporate-supported editor, and asked us what we wanted. Rather than just filling out a questionnaire, I went into his office. The guy takes courses at Wang Institute where they have a lot of VAXes, and he had used TECO. As soon as the word TECO got out of my mouth, he kicked me out of his office. Two months later, an old DEC customer came to work at Wang. About a week after he had been there, he came up and asked me what editor I used. I told him about one that was slightly better than the official supported one and pointed him at this guy's office. Same thing -- he went in and asked for TECO and got kicked out of the office. Jim Flemming: While we're on TECO, I've got to tell a story about Tony. I had received some TRACK performance data from a customer in the field, and there was something in particular I wanted to look for in the data. It turns out the ASCII TRACK file is not particularly easy to deal with in a Fortran program. So the first thing I did was I went down the hall and found my friends who are SITBOL giants and asked them if they would write me a little SNOBOL program to extract the data. They scratched their heads and messed around, and after a couple of days, why, they weren't certain that they could do it. It was about 11:15, and Tony said he could do that in TECO. By 11:45 he had extracted the data that the SITBOL wizards couldn't get out of the file for me. Richard Greenblatt: Just to stick up for poor TECO, I really think that it may not be realized what a powerful programming language it really is. Many of you may know about the EMACS editor which is quite an elaborate editor with a very fancy, easy-to-use human interface. It has probably set the standard for a large class of what might be considered the state-of-the-art in easy to use editor interfaces. That of course is programmed in TECO. The programming is very compact. I might even go so far as to say that with the address space on the PDP-10, if you didn't have something to program it as compact as TECO is, you wouldn't have much space left for editing your buffer. By now, people have implemented EMACS-type interfaces in quite a few other machines and languages, for VAXes, for LISP machines, etc. But the amount of programming involved and the amount of run-time space it's taken to do that is many times what's involved in PDP-10 EMACS and also in many cases it has less functionality. So, TECO does really have its points as a programming language even today. Alan Kotok: I can't let that go by without remembering the LISP interpreter that Page 16 Dave Gross and I wrote...in TECO! Bob Clements: One of the first compilers that ran on the PDP-1 was DANTRAN which Dan wrote in PDP-1 TECO immediately after having written TECO. It was not the world's most elaborate compiler, but it took A = B + C and complied up the appropriate PDP-1 instructions having been written in TECO. Dan Murphy: Well, that's right. In fact, a number of the commands got added to TECO back in those days because of these peculiar hacks that we were doing with it. I don't know if I should tell this story, but I'll give it a try. I didn't come from the model railroad club at MIT. I came from the student radio station, as did Bob over here and a few other people. Whatever the Hackers book says, there WAS another source of some of us there at MIT and that was the radio station. The original looping control in TECO on the PDP-1 was a sort of open parenthesis, condition to be tested, stuff to be done depending on whether the condition was true or false, followed by close parenthesis. This came about from the fact that one of the guys at the radio station had a particular talent. He would read newscasts in a Chinese dialect. I hope no one takes offense -- this was 1964. He did that by simply mentally reversing all the l's and the r's in the text as he read it. And we decided that it would be a darn good idea if we had an editor or some computer program that would do that. Of course it took us one pass to realize that we couldn't just change all the r's to l's and the l's to r's since we'd end up all r's. So the original looping was put in there so that we could go through, search for an r, change it to something else, search for an l, change it to an r, and then change the something else to an l, producing the text all ready to read. For whatever it's worth, that's where looping came from. Clive Dawson: That'll be one of the 40th anniversary trivia questions! Does anybody have any closing comments? We only have about 3 minutes left. Glenn Ricart: The DEC-10 was one of the first computers that I know of that saved a life. One of the chemical structure databases on the PDP-10 at NIH was used in 1974 to determine the kind of antidote that was needed to save the life of a child who had accidentally swallowed a very bizarre compound to which no known antidotes had been understood at that time. Clive Dawson: I want to repeat what I mentioned at the beginning, which is that it was totally impossible to even begin to think of all the people who deserve the title "36-Bit Pioneer". To all of them, and to all of you up here, I just want to say: Thank you for making it happen for us! ------- --------