Stretch Reunion Special Lecture Fred Brooks, George Grover, Harwood Kolsky, Erich Bloch September 28, 2002 Computer History Museum



Download 83.9 Kb.
Date28.05.2018
Size83.9 Kb.
#51893


Stretch Reunion

Special Lecture
Fred Brooks, George Grover,

Harwood Kolsky, Erich Bloch
September 28, 2002
Computer History Museum

IBM 7030 (“STRETCH”) REUNION TRANSCRIPTS

General Notes
On September 28-30, 2002, a unique group of computer professionals met in Poughkeepsie, New York, to celebrate the IBM 7030 (aka “Stretch”) computer. This computer, first shipped in 1961 and over five years in the making, is one of the most remarkable computer products ever designed. With dozens of new architectural concepts that revolutionized the industry as well as the nascent field of computer science, Stretch embodied the very best of IBM—the best people, the best technology, the most demanding customers.
This transcript is a verbatim transcript of interviews conducted during the course of the Reunion. The Computer History Museum, home to the world’s largest single collection of computer artifacts, is proud to offer this series of transcripts as part of its ongoing mission to preserve and present the artifacts and stories of the information age.
Every effort has been made to check the accuracy of this transcript. All interviewees were asked to verify the relevant transcript. When they replied with changes or comments, this is indicated in the footer of each document’s pages by the phrase “Checked by Interviewee.” Note that most of the subjects did not respond to CHM’s request to proofread their comments.
If you have any questions or feedback relating to this transcript, please contact Dag Spicer, spicer@computerhistory.org.

Fred Brooks: I teach Computer Science at the University of North Carolina in Chapel Hill and my first job after graduate school was as associate engineer working for Werner Buccholz on the Stretch. I've been asked to lead off this afternoon by talking a little bit about the influence of Stretch on later machines, and that many of you in this room who are able to do that better than I but Gerry Blaauw and I wrote a book that went through the evolution of computer architecture and the process and we had an opportunity to look at that question, so at least I'm prepared .

I am indeed heavily indebted to the book that Bashe, Johnson, Palmer, and Pugh--and I guess Emmerson is here--did and I found many facts that my aging memory wouldn’t dredge up , I'm indebted to the work that Gerry did in preparing that joint book. The story that I had up on the first slide I think is the story in a nutshell and that is stretching is great exercise--it prepares you to win--and I think it's very evident from looking at the history that this was the reason why Ralph Palmer wanted to see the corporation undertake a super computer effort that I think he was under no illusions as to whether it would make money or not, but he knew that the company, and it was part of this thing, the company was behind in circuits, in packaging, in memories and needed a push to get it into position.

Now that strategy worked great, but it worked even greater than he had anticipated because of the fact that along came the opportunities to bid on the four computers that Sylvania was buying for the BMEWS system and the requirement was they had to be transistorized computers, they had to be high-performance computers, and they had to be delivered eighteen months after the proposal . Well, they were, the first one was delivered in November, the bid was made I believe in May or June of the year before, that’s eighteen months from start to finish. Now the strategy which was adopted--and this is George Monroe who was engineering manager of that program--the strategy was worked out between George, Ralph Palmer and others, and that was to take Stretch circuits, Stretch memories, Stretch I/O devices and take 709, not only the 709 architecture and manual, but the 709 logical equations and implementation and run ‘em at a faster clock rate and it was only by this using a pre-designed implementation, a pre-designed architecture and a pre-designed technology that it was possible to do it.

Well the 7090 went to become the dominant scientific computer in the United States of its time, it went through generations, the 7094 and then later the 7094 model 2, several hundred of ‘em were sold and that was an immense number of computers of that size in those days. The same strategy was later applied to update and transistorize the 705 model 3 to make the 7080 and then the I don’t know what, I think was the 7080 model 3 was it , and maybe some of you know the degree to which the Stretch technology was also used to make the 7074 which was a transistorized- . . . were the same, my recollection is the memories are the same, does anybody know . I believe that the Stretch technology became the basis for the DSD whole product line including the 7074.

Then along came the system 360 concept which was a cross division, and that’s where Bob Evans and I fought on opposite sides for six months because I wanted to get the 8000 series, a DSD product line out now and he was willing to say let's wait two years but go for one stretching across the whole company product line and he won and he was right and I was wrong. And then to my other amazement he asked me to run the system 360 effort and I was dumbstruck, because in the middle of that six month product fight at one point at the end of February, we started to fight in January and we fought ‘til June , he called me on the phone and he said “Fred”, he said “I want you to know you got a raise”, and he gave me the amount, I said “Well Bob, thank you very much”, I was surprised but we were really going at it, he said “I want you to know I have nothing to do with it” . And he didn’t raise his voice.

Alright, well the 360 story was one of more market dominance, if you look at the annual reports for those years you suddenly see this going along like this and then it goes like that and that was the result of many, many people’s efforts and many of whom are in this room, but it directly derived from Stretch, and I'm going to tell that story again and again in a nutshell.

So let's start with the circuits. I think a lot of the initiatives saying that the IBM corporation had to move from vacuum circuits to transistor circuits was in fact Ralph Palmer’s. Bob Henley came on and was a key there and he hired Joe Loeb who said he said we oughta be moving to drift transistors instead o’ surface barrier transistors and Palmer’s leadership took effect when the time came to bid a supercomputer for Livermore and they were bidding against Sperry Rand. Their proposal was one in which I think Livermore wanted to pay a couple o’ million of dollars or thereabouts, Palmer said we oughta use this as a vehicle for carrying us into the drift transistor circuits and proposed essentially a non-responsive machine, that is one that was way overpriced by those standards and was gonna be late. And Livermore chose the Sperry Rand bid which Pres[per] Eckert and others had prepared for and the LARC was built by Sperry Rand and delivered to Livermore. But then the team started looking for an opportunity to bid that machine that was made out of drift transistor circuits and get somebody to sign on for it as a way of dragging it into existence. Along came the opportunity to bid for Los Alamos and that is then what happened. So key technical concepts were the notion of drift transistors and then Hannon York came up with the current switching circuits as a way of handling the noise that was created, and although Stretch started out like advertised as a ten megahertz--ten megapulse machine the--Loge and Dunne will finally agree according to the Emmerson and others’ book on the 29 nanosecond per gate goal and in fact that’s about what was done.

Meanwhile, as the early computers book describes a major effort was going on in packaging in Endicott and the SMS packaging came in and made it possible to provide really an effective package for the transistorized circuits. When they tried to put it into the Stretch technology, Eric [Bloch] who by this time was engineering manager of the Stretch program, Joe Loeb had been the first one, saw that the signal length problem of how you get all these things close enough together to get wires shorten up just wasn’t gonna be solved that way and he made a push for a double card package which became then the standard technology for the high-performance machines. And so as I've already said, this was crucial for the 90’s, for the 7090’s, crucial for the 7080’s, crucial for the 74, and indeed it was the technology for the data systems division to hold the high performance machines until the SLT packaging with the semi-integrated circuits came along.

Now there’s a similar story for memories. Work had been going on a new ferrite core memory. I think it started out the early core memories as I recall were 50 mil inside and 80 mil outside and they were working that awhile and then said okay we ought to be able to get the windings into a 30 mil inside. You know, there's a standard story that the generations of cores they used the punched out hole of the previous generation 80/50, 50/30, 30/22 and so forth were the sizes. Greg Constantine had come up with the load-sharing matrix driver as a way of managing the currents against those back voltages and this was a hot memory, so a lot of things were tried including Freon as a ways of cooling it. Eric can tell you more of that story. They ended up with transformer oil and so the memory as delivered on Stretch was an oil-cooled memory. Later it used smaller cores--esed the old holes--and made it air cooled and got it on later 7030’s and 7090 programs down to 2 microsecond cycle time. Stretch was the first machine that I know of to use four-way interleaving on the memories, and so the instruction memories that were two instruction memory boxes and they were two-way interleaved and the data memories were four-way interleaved and very important was the notion that, you know, we might not be able to make memories work infallibly.

Of course on the 701 and 704 there hadn’t been any checking at all and on the vacuum Williams tube memories, you know, I remember the 701 was the machine I learned to program on, it made a main free error time of about five minutes, between five and ten minutes , you had to roll out the drum every five minutes and you had a real good chance of getting it to go again. But when they put checking on those memories they had to throw the memories away because, you know, this was the 702, because it failed often enough that if you were checking and found out it was failing you couldn’t make any progress and so . The 705 switched from a William speed memory to a core memory and got to the next level of reliability.

What Stretch was talking about doing lots of operations per second and it needed a higher degree of reliability and one of the luckiest decisions, not just wisest but luckiest decisions and it's as important to be lucky as it is to be wise sometimes, was to put single error correction, double error detection [SECDED] on that memory. This had two consequences, one is since the word length was 64 bits this added 8 bits and so, you know, that’s a twelve-and-a-half percent increase in cost if you didn’t have any logic circuitry. But guess what, when the 7090 needed a memory they could get two 36 bit words, of course unchecked alright , give me that 72-bit word length and so that’s what I mean by lucky, that’s just lucky.

Alright, now the other place where the wisdom showed was in the acceptance test, and Harwood can correct me on this, but my understanding is that the requirement was that it run for a month I think at something above, and I forget, 90-what percent, 92, 95, something like that, and she went chugging along great and was just hovering right above the line there and then one of the memory . . . either one bit drivee or else one sense amplifier failed completely, and for the rest of the acceptance test they just ran it the way it was, there wasn’t time to stop and fix it, it would’ve ruined the statistics and so it went along single error correcting every single memory [access] .

Well as I said this memory made the 7090, which was six times the 709, possible and it became the standard memory, meanwhile the memory group developed what started out to be half-microsecond memory and ended up as delivered as a seven-tenths microsecond memory, if I recall--Emmerson, is this right--I think it was a two core per bit memory to get that speed, I think that’s what was delivered on purpose . Certainly more intensely motivated and publicized .

Emerson Pugh: I think you’ve read my book more recently that I .

Audience member: It was word-oriented, word-oriented.

Fred Brooks: Okay, alright, so originally that was gonna be part of the Stretch delivery and that got taken out of that contract for scheduling and other reasons. But it is what was built and used on Harvest for fourteen years.

Another important story, and Harwood [Kolsky] can tell you this one in a lot more detail, was the notion of instruction pipeline. Any of you who have a PC today are aware of the kind of performances the machines will deliver, anybody’s laptop is faster than Stretch. In many cases this is the only technology I know in which over this length of time we’ve seen more than a thousand-fold increase in performance-to-cost ratio and you can take it either as performance or as cost, and I know of no other technology where you have that choice, okay. So you can get one that costs a thousandth as much and runs as fast, or one that runs a thousand times-and as a matter of fact the ratio’s bigger than a thousand now. Well a key part of this concept today people we’re talking about, you know, maybe, maybe even though any individual instruction takes several clock times, maybe we can pipeline it so that we are able to issue one instruction per clock. Now a days people issue four instructions per clock, six instructions per clock, but it's the same pipelining concept that John [Cocke] and Harwood came up with and tested on Stretch.

If I recall correctly Stretch had eleven instructions could be in execution at the same time, some of ‘em being prepared, some of ‘em waiting data fetches, some of ‘em having indexing done, and then some of ‘em, after execution, some of ‘em waiting to be stored. And now, Seymour Cray built a machine that had similar kind of properties like that afterwards and he made a different decision: that is if you want to worry about whether you were interfering between the fetch that you're about to make and the store you just specified that’s your problem and you better program around it ‘cause you're gonna be hand probing this thing. Not Stretch. In Stretch the logic is there, it automatically did that scheduling and of course you had the same kind of concerns that you could have with today’s machines about whether you're gonna have pipeline delays because you’ve misprogrammed it and you can speed up a program by getting rid of the delays. But it would run riot okay? The simulator was crucial and I think Harwood principally did the simulator and, at one point according to Emmerson’s book, more than a thousand simulator runs were made to change the speed and tune the speed on application kind of problems. A crucial concept in anybody’s processor from a PC on up to date.

The arithmetic started out to be a 1 microsecond--well matter of fact first quote was like seven-tenths microsecond floating ADD promised the kind of a 1, came in at 1.4, with only a 2.5 microsecond floating multiply on a nine microsecond floating device. Now most of you will recall that in multiplication, the length of time the number of things you have to do goes as the square of the word length, and we’re talking about a much longer word length, 64 bits of which 48 bits are fractions, so you think multiply would take a-a lot longer than floating add. Well I think it was magic here and Owen McSorley was kind of the leader of the group that took on the multiplication challenge, and built a the most sophisticated multiply that had ever been built up to that time and one of the most sophisticated multipliers ever built that would handle up to six multiply digits at a clip, alright. So if you had six zeroes and six ones it was one add cycle would take care of that, and in and for cases where they weren't all zeroes and ones then you still would get many multiplier digits.

Well it turns out divide is a lot harder to accelerate and so when the smoke cleared not as much circuitry was put into it but an important lesson was learned, and that is on the 704, and therefore on the 7090, multiply and divide took the same length of time, well really divide’s a lot harder to do, but people were used to ‘em taking the same length of time and so if you wanted to divide something by 2 you divided it by 2, but you don’t have to divide it by 2 if multiply is really faster than divide you’d multiply it by a half and it's just as well. And it turned out that when we did compile our studies something like half of all the divides in 704 and 7090 programs were divided by constants and could be replaced by multiplications. And so consequently it wasn’t nearly so important to get the floating point divide time down once this fact was discovered.

Now, our next big important notion here which had been seen as important in the business computers, the 702, the 705, the 705 model 3, the 7080, the 650, was fully checked, the arithmetic, I think 650 may have been—-well Univac I was the first machine that was fully checked from one end to the other, all the way through. Well so was Stretch arithmetic fully checked and it used a fast carry ripple adder and this arithmetic concepts and especially the multiplication concepts were picked up and directly used in the 360 models 70, 91, 95, arithmetic units, you know, that’s just one of the places where Stretch technology just carried over.

Input / output is another place, the child concept had been developed for the 709 and I see Larry Kanter here and he’s one of the well, you know, were there four of you that shared, three of you, who were the other two?

Larry: George Monroe and Carl Christensen.

Fred Brooks: Carl Christensen, alright, shared the patent award for inventing the notion of a channel. What is a channel, well it's another computer, it's really a multiprocessor, where you have a specialized computer that does I/O feeding into the same memory in which you have your main processor. A concept that has been—[that] everybody uses. Now the Stretch team made another step forward and that is what today we would call a virtual channel. It had sixteen channels but it had only one set of channel hardware, and so because of the fact that I/O operations are inherently slower byte-by-byte, it's possible to timeshare that hardware among the sixteen channels. And the planning on this was done by Werner Buchholz here, and the engineering team was led by Herb Wild, there’s several important advances here. One was Werner came up with this general I/O instruction set, before that machines had had bushels of different I/O instructions, you know, rewind tape, move disk arm, poke card out in the stacker , Well, Werner generalized these to say there are two directions in which you move data--in and out--and there are two things you do with it, either you put it on the medium or else you use it to control the mechanism. And so that led to a general clean set of I/O ops [operations], and the first standard I/O interface. It was not the standard I/O interface the corporation standardized on for 360 because that technology had moved on, but it was the first concept of having a standard interface in which you could plug I/O units and channels across from each other. And these concepts were exploited all over system 360, the multiplexer channel, for example, even on the smallest little 360 model, 20, 30, were virtual channels with up to 256 terminal channels being handled by one set of hardware and, on the model 20 and 30, that was the same hard-identical hardware that was also the mainframes, timeshared every which way. And the selected channels on the models 20 and up were essentially using this same kind of concept of timeshared virtual channels, so.

A machine like Stretch which essentially started out as a one of a kind, you don’t want to spend a lot of money doing development of new I/O devices for them. And one of the strengths of the IBM 704 against the Univac 1103A its chief competitor in the market, was the rich collection of I/O devices that the IBM machine offered on the channel directly available as opposed to offline kind of stuff. And so the notion that Stretch would be equipped with a full set of I/O was important but it was essentially a full set of standard I/O except it needed a high-performance memory backup contraption. And so what was proposed and developed and later turned into the product that was used on the 360 as well, was a disk in which, instead of activating one read hit at a time one disk at a time, you comb moved all the heads in and out and all the heads were active and you read it off in parallel. Well notice that this conceptually means that at any given setting of the comb you have a magnetic drum just going around and you're reading the data in parallel from it, but you can choose among your drums at very high speeds. And in fact the Stretch disk as proposed--Eric says in fact it's deliberate--and alright, had two combs and is that-is that right, everybody remember that, one on each side, two combs going in and out so that you could up an eight million bit per second transfer rate, some of you may remember the 360’s we got up to three million bits per second and that’s on the standard I/O channel. It only had two million words and that seems laughable to us today, sixteen million bytes, well, you know, how many-how many . But remember the main memory on Stretch, which was an important advance, was a quarter of a million words, a million bytes and was eight times larger than the 7090 memory so a memory jump was really important an advance. So was this disk.

Now in architecture I think the most important contribution and one that we later adopted in the 360, was the notion of switching from a six-bit byte, which would not accommodate lower case characters, to an eight-bit byte which would, and this was Werner and Steve’s passion and they made it happen, we later adopted it after another fight to the whole product line. Now the economic consequences of making that shift are immense, because you have to--if you're going to do it for a whole product line--you have to redo every I/O device, every one, and that’s a big deal. But I think it was very--it was full of foresight to say it was gonna be important to process language with these machines, and to process language we’re gonna need to be able to deal gracefully with upper and lower case characters, and the eight, you know, you could do it with a 7-bit byte, the 167 did it and I think the switch to eight was very wise, the big memory was very wise and a thing of great importance was the notion that you should put in a machine all the facilities necessary for the program to keep control so that the operator becomes only the hands and feet and not the guiding mind for the operation of the machine. And that requires an interrupt mechanism, a real time clock of some sort that they can interrupt you to stop close the loops, memory protection so you don’t write on some--on the operating system just ‘cause you were stupid or not malicious, and privileged modes. So that became very important and then that meant then that you could do multiprogramming and you could do the multiprocessing I/O in a more general way than just with the basic channel.

Another important concept was lots of address registers. Now the Stretch only had two data registers, that we can relate, and we later generalized from that, but it already had the sixteen index registers, up from three in the 709 and 7090. Variable field made alphabetic and decimal data integrated indexing and I/O and then the 64-bit floating point which has slowly become a standard.

Then the last thing I want to talk about before Tom [?] takes over is software and George Grover can elaborate on this, but the operating system did provide some supervisory capability. It was an important Fortran compiler and an assembler and I'm sure George will talk more about that. But I do wanna specially mention Ted Codd’s experimental operating system. Ted said “Now we can multiprogram in this machine, it should be possible if we design an operating system right, to multiprogram programs that were not designed to be run together”. In other words I can fence ‘em apart and turn ‘em loose going at the same time, and because I/O is so much slower than internal processing, I can take jobs that have lots of I/O and jobs that have lots of internal processing and share the machine and get more total work done. And so Ted and his team, some of whom are here today, built the first multiprocessing operating system, I remember reading in a British conference report and I think it was Stratchie who said, you know, it should be possible to build a machine that will run multiple programs at the same time and enable you to do kind of timesharing. And at the end during the comment period Ted got up and said “We have done it” , and went on to elaborate a little bit in the comments. Major contribution, crucial background for all the later multiprocessing operating systems. So at that point let me conclude and let Eric assemble the panel.



George Grover: This is not a new situation for software to be in at the hands of hardware engineering . I want to begin by saying I am gonna speak from the software perspective, great to see so many software faces in the audience. I have not written a book on this subject, but I will and I will not be able to do justice to all of the things mentioned, the good things that so many of you have done, but I’ll try to hit the highlights. We were faced from day one on the software side with schedules for shipping that seemed very ornery. We were faced from the outset with very difficult schedules to meet and our first priority throughout was to undo whatever had to be done to be able to ship to the hardware. We had two different compilers, Fortran for Stretch and the scientific market, and Alpha for Harvest and cryptological applications. And that was a tall order and so to try to make it a little more easy to handle we came up with a scheme for doing one common compiler and feeding at the top the source languages then and mapping into a macro language interface just below and going down through various phases and out the bottom with software for Stretch on one side and Stretch Harvest on--Harvest on the other.

The result of this approach was a mixed success. We met our schedules, we, on the Alpha side, things went pretty well. On the Fortran side, the performance was somewhat disappointing and to the point that we then subsequently, after the first release at some point, put out a second Fortran compiler which had substantially better performance and in part due to an outstanding optimization job governed by Ken Planbeck. Looking at that project from a development perspective it was somewhat mixed, but from an add-tech [?] perspective looking at the ultimate consequences on other products it was a success and it was more of a success than I realized until fairly recently.

Today, IBM’s main product and compiler is called the XL family, compiles many languages to many target systems and it is a direct descendant of our forty year ago common compiler system. It has a similar cascading design, and there were a number of intermediate events along the trail from the one to the other and the key to a lot of this was that Fran Allen was involved in a number of compiler efforts. And I have to say, I used to say Fred, I saw the tongue-in-cheek, but I used to say that software technology doesn’t exist, it's only folklore and therefore the best way to transfer the technology is to transfer the folk . And that’s not doing software is well the prime technology today, but nonetheless it is also true that that’s the best way to transfer and this was an outstanding example of that. There was an ACS research project compiler which focused very much on optimization methods with a scientific basis. And also which was able to get good results on a number of different languages, so it was--for a large class of languages, it was a language-independent optimization scheme.

The next stop was the PLA compiler for IBM RISC projects, and here in Research both Fred and John Cocke were very active in this area. And then they came up with a variant of the common compiler system, combined with these ACS optimization methods. And they processed two input languages, one the PLA and the other Fortran, through the same common compiler. This product then just kind of evolved and became--by incrementalisms and improvements--it became the XL compiler product that is there today and is so powerful.

So this is a pretty good story, and now I’d like to jump back to the-something very close to the hardware interface. I heartily agreed with Fred’s perspective that the possibilities of multiprogramming and multitasking were huge implications for software, that they came of Stretch. So much so that it was adequate to keep software developers busy for multi-years , multi-releases. The hardware interface, strengthened still further in the 360s with the addition of base registers, there and later in the 370s with dynamic hardware relocate. So it was a long story to get there, and I cannot resist remarking that when the Windows, well DOS and then Windows, PC saga has been a very long one in this respect, and it's not clear to me that they're yet, and I speak from the Millennium [Windows Me] level, and that basically they’re trying to do the same thing that we did quite a long [time] ago. The thing that makes it so difficult in my mind is these two small words, multiprogramming and multitasking. The key requirement is that all resources are shared dynamically, everything, memories, real, virtual, caches, disks, access times, CPU-CPU’s and tie helped itself in the case of reentrant stuff, communication bandwidths, etcetera, just profound implication on the software structure.

George Grover: (cont’d) … both at the prospects and made a decision not to go for full multiprogramming and multitasking because we didn’t--we thought the risk was too great and against those schedules. But instead we picked a special case which was spool, and which involved a good deal of multiprogramming. The spool program was a special program, which was part of the system, and that had some advantages, a fixed storage amount, you could use the “disable interrupts” function when it was necessary to avoid synchronization problems, and spooling essentially carried forth a software level in all the future systems. We did a little overlapping through our job scheduler of MCP with tape mounting and that again was carried out and we utilized the interrupt system as had been planned to improve the error alarms and diagnosis and so forth.

I agree strongly with what Fred had talked about on Ted Codd’s project. This was not a development product but it was a very good running prototype. It was an ad hoc effort which was extremely successful, in my mind it assured the concept feasibility with running code and it assured some hardware design to do that. And as most of you probably know Ted was an amazing guy, he followed this by going out to California and bringing relational databases into the fold which is a now just huge achievement.

This is my last foil, I just wanna say a little bit about the Alpha language which was designed by Fran Allen, it was for Harvest, was a very high-level language, it had some properties which later appeared in other high level languages. It simplified the streaming unit usage, particularly on the Harvest machine, so that the programmer could utilize it without having to understand it, and that was quite an achievement . The whole system was just amazing, it had tractor tapes, you could . . . one statement in the Alpha language could be executed for days . It was the first high level language to allow multiple data types to be assigned to a single data set, which was a useful thing, and which got added to some other languages later. It had an implicit data declaration, wherever it was possible, when you had a calculation, you didn’t have to define the results, they were inferred from the operands and from the input data types and it did this for very large complex structures.

Some other high level languages took the same direction but none ever went as far as Alpha did. The other thing is that the Alpha language was a successful enough that the customer later made a version of it called the Beta language which was extended in a way that it could run on hardware other than ours. So and this was, as you all know this was a customer who had a lot of machines . That’s a very highlighted look at it.


Harwood Kolsky: Well preparing for this Stretch / Harvest reunion has really brought back a flood of memories and if I could be just a little bit poetic I’d say that in our youth we were touched with history. Serving as a member of the Stretch team when the computer industry was new was really a remarkable time and I think all of us must feel that in our souls. I’d like to refer to the period from 1955 to ’63 as the Stretch era, and that that whole period in there was-Stretch was really sort of the top machine being built at the time and it was certainly everybody talked about it even though most of the activity among competitors were smaller machines. Of course this hasn’t been forgotten but it certainly has been overlooked. Like for example I notice that in Hennessy and Paterson’s eight hundred page tome on computer architecture, which I used as a text one time, there was about seven lines devoted to Stretch . . . however they did spend a lot more on ‘360 and ‘70 and of course on the DEX VAX a large part of the book.

My position on the project was really sort of unusual because I was working at Los Alamos as a physicist and we had a lot of machines at that time too, card machines and probably what was available in the marketplace. And when the 701 came out we had version model number one of the 701s was delivered to Los Alamos and I was one of the people who had pushed hard that we get this machine because we had been using IBM and its punch card machines, mostly the card programmed calculators, CPC at that time was a very popular--I used to refer to it as the Model T of the computing industry---it spread throughout the industry and got people used to the idea of programming problems rather than just plugboard wiring them.

Anyway, as part of this the proposal that was made to Los Alamos which was this--it was mentioned earlier--was part of the rivalry between Livermore and Los Alamos which was sort of friendl. Rivalry but it goes on to this day, you know, so if Livermore is gonna get a supercomputer then by gosh we’re gonna get one, you know. And so when IBM came with their proposal it was very it was really received with a great deal of enthusiasm. I’d say by everybody except the members of the group that was building MANIAC computers which was a Los Alamos home-built machines and they were a fairly powerful group at that time. Anyway, the Los Alamos IBM mathematical planning group was set up, there were nine members from Los Alamos on the team and they included chairman Bengt Carlson, who was the head of the computing center, Max Goldstein, Ed Vorhees, and Jack Worlton, they were all from the computer center. Then there was Roger Lazarus and Mark Wells who were members of the MANIAC team, and Roger was certainly a good friend and we used to debate endlessly about the virtues of different machines, and then Bob Frank, Dave Woods and I were the people who represented the users of the big machines.

In 1957 I joined IBM and continued on the committee except sitting on the other side of the table now and which resulted in, well if not a split personality at least a Stretched personality, and Cuthbert Hurd of course and who all of you I suspect know at least by reputation was very happy to have me on the team, just as because I've been one of the 701 supporters but he sort of wondered whether. . . questioned my wisdom when I discussed it with him whether I should join IBM or not, and I think he was, you know, probably less concerned about my career than he was about that I was more valuable as a customer than an employee .

Anyway it's very nice to have the book here, I think that Eric Knutsen did a tremendous job on the book for this event and dedicating it to Steve Dunwell and to Sully Campbell was a excellent idea and so I’d like to just say give a sort of a personal note about an experience that I had with each of those two gentlemen,

Certainly Steve was one of the people who convinced me that I should join IBM and we certainly all owe a debt of gratitude to him for keeping the project going against an unbelievable amount of opposition within the company. I can recall, after I joined IBM, sitting and reading which people were saying nasty things about these people trying to build things out of transistors, you know, after all ninety percent of the money is coming from punch cards . Anyway, of course, Steve ended up because of the fact that the Stretch machine was not considered financially successful,l they wanted the very same people who were manufacturing hundreds of 7090’s were complaining about Stretch being a financial failure but anyway there was an incredible number of ideas and things came up in all the discussions among the Stretch people and projects and somebody would say “What about doing this, what about doing this” and so on and I know a lot of these ideas should've been recorded at the time because they would’ve been the source of future patents and so on, and I'm sure that, for example, John Cocke’s ideas bubbled from him, you know, like water from a spring and even if half of them had got written down we would be way ahead of the game.



One time when I was talking to Steve Dunwell shortly after I came to Poughkeepsie I said that my experience had been that a lot of computer time is wasted because you start with a large program running and some of the boundary conditions which you fed in are incorrect, not what you expected, and the program runs and runs and runs and is nonsense. And I said “I propose well why don’t we attach a TV set to the computer and so we could display the graphs or maybe even diagrams which are pictures of what calculation was doing at the time, and then we ... the problem originated tell right away, you know, if there was something wrong with the initial conditions and cumulatively brought the program and fix it.” And Steve listened patiently to this statement and he said “Well that’s a very good idea”, “it should be easy to do”, “however we’re- a little bit shorthanded right now” “and when I have a chance I’ll put a bright, young engineer on the problem, it shouldn’t take more than two or three months”. Well it took a lot more than two or three months, in fact I’d say two decades is more like it or maybe the bright young engineers were all busy with something else at the time. Anyway that’s a good example of Steve’s ability of handling and managing technical people .

Not Sullivan Campbell. Really one could spend a whole afternoon on stories about Sully, but he was certainly a man for all seasons, he enjoyed life to the fullest and lived life on the edge. I met him first when I came to Poughkeepsie on one of the trips on the, you know, mathematical study group and we were put in the same office together and it [was] soon determined that we found out that we both had lived in Kansas and had that in our background and of course he was a great storyteller and [would] keep anybody enthralled who would listen to him, he just--he was really a very interesting person. And we were invited, my wife Frances and I, were invited to a spaghetti dinner at his place shortly after we arrived here and then we met a number of his other friends and I know our friends, certainly John Cocke and T.C. Chen and George Swift are all here, I'm sorry that more than I can say that John isn’t here. Sullivan was a meteorologist by training and he was very interested in aircraft--he had his own plane--and I remember one time where we worked together on a proposal for the Air Force called 433L, which was a weather system. We lost the bid but we put together a lot of ideas as a result which were later used. At one time there was a bidder’s conference down in Washington which was called--it had something to do with weather forecasting--and it was called rather suddenly and the argument was “well we gotta have some representation at this meeting,” and the timescale was very short so Sullivan said “Well we can fly down in my plane, attend the meeting and fly back”. Sounds like a great idea and we took off, we checked the weather of course and there was rain expected that evening but we’d be back long before then so that’s no problem. And we started out, everything was nice and we made the flight down to Washington and landed in a small field, you know, south of Washington there in Virginia, went to the meeting. Well it turned out that the meeting was really not of interest after all, and it was not what we thought it was, and the meeting dragged on and on and we ended up taking off to come back about an hour later than had planned. And when we started coming in to the New York City area we saw these massive dark clouds in the northwest and this didn’t look good and it started again to get overcast and we were looking down carefully and then all at once I saw this plane coming up, I think it probably was from Peterborough, I'm not sure, coming up, you know, up and at us like this, and I frantically pointed it out to Sullivan and he took evasive action and the plane went on by but that was really close, living life on the edge as it were. We followed the Hudson River and it kept getting more and more dense and finally all one could see was this dark shape of the river down through the clouds and Sullivan didn’t have a instrument rating at the time, he got one later, but he didn’t have one, and so we were supposedly on VFR, Visual Flight Rules, and so the question became how soon do you make that turn away from the river to go towards the Poughkeepsie airport and we discussed this for quite some time .

It seemed like a long time and really, you know, not very many minutes but finally came to the conclusion that now was the time to turn and follow our compass direction that we thought was the airport and Sullivan came down as low as he dared and finally saw some hills through Putnam County, you know, looming up in the fog and we knew we were not too far away. And then just then we started seeing lightning flashes ahead of us but right on schedule there was a sort of a break in the clouds and you could see the airport just down over to the left and so we came down and circled in circled around and landed just as the thunderstorm was passing through and the runway was all glistening with rain and we parked the plane and ran through the rain into the- inside and the people there couldn't believe that we’d actually just landed , the airport is closed . So anyway that’s an example of living life to the fullest with Sullivan .

I did want to mention a couple of other things, one of them was T.C. Chen, who I wish could be here, and he was a master of being able to explain performance problems to customers and he did a lot of very serious work but he also was extremely good at this ability to explain them and to get the point out that they were programming things in the wrong way and that you really shouldn’t be storing into the instructions and so forth , things of that sort. So I remember that the statement used to be when a customer was getting really unhappy Sullivan said “they need another treatment from Dr. T.C.” So anyhow that I really wish that he were here because he could he could really explain this problem of overlapping and so forth better than anyone that I could ever imagine. Let's see is that about enough time?

Eric Bloch: I want to go back to May 1961, which was the delivery of the Stretch computer for Los Alamos, and that’s about forty-one years by my calculation and I must say and I’ll paraphrase that’s quite a stretch . But I'm glad to see so many of us here together, especially considering the alternatives . But our presence here makes it clear, that Stretch always had and still has a meaning to all of us. To me Stretch meant its people, not only its people at IBM but its people at Los Alamos and at the NSA. The task of designing and producing a computer system was obviously was not always clear, it was obviously the main reason for the existence of Stretch, and probably for all of us, including I would say Steve Dunwell, we were faced with such a task was the first time in our careers and in our life. And this was a daunting task probably more so than we understood at that time. But looking back at it, if you had really understood fully what was demanded and what could be achieved it's clear it should have been not only daunting but frightening indeed.

It became slowly clear over the years and decades and Fred Brooks and George [Grover] made that particular point, that Stretch really was a fountainhead of ideas and of concepts, and I think that it's probably the main emphasis that we should put on it. Eric Knutsen’s questionnaire asked what job each of us had, and mine was very simple, my answer was very simple, and very direct, getting that sucker working . And I know this sounds very flippant, but I mean this with all sincerity, and a great love for the project, and I just want to reflect on a couple of instances that occurred around Stretch and around the same time as Stretch.

One essentially clearly shows the effectiveness and the productivity of Stretch and of Harvest. And it reminds meof the Harvest retirement celebration in 1976. Jim Willard obviously was there and so was Bob Evans and Jim Pomerene and many others and myself and Frank Carey. And during the luncheon, especially the NSA people, recounted all the things that Stretch did, and that it exceeded their expectation, especially they thought it would only be worthwhile keeping the machine around for three or four years, and this was fourteen years, that the machine was very effective and very productive. And I could see Frank Carey’s face getting redder and redder by the minute, and I was unlucky enough that I happened to be in Armonk at that time and I went down with Frank on his plane and came back with Frank onthis plane and soon as it the plane was in the air he turned to me and said “You know, you engineers don’t know a darn thing, this darn thing only should've lasted seven years” . And even a battery manufacturer knows how to design for three years and no more .

My second story has an international flavor, and it was about Aldermarston in England. Aldermarston got one of the 7030 machines, one of the first 7030 machines delivered in 1962 and that was just about the time the 360 model 40 was being designed in Hurlsley. John Fairclough, who unfortunately cannot be with us, I wish he could be, was in charge of the model 40 and I was there and Bob Evans and Fresal [?] were there at the same time. And we were just about to leave to go back home and it was early July. Evans gets a phone call from the States “You better not go home without stopping by in Aldermarston because the machine isn’t working, and they're pretty unhappy”. So he rounded up Fresal [?] and myself and we went to see the people in Aldermarston. We were received by now I forgot his name, what was it, yeah I forget, anyway he--you say so I don’t know, anyway he and his two assistants, two programmers, women, received us and I was never as reamed out in my life as I was that day and especially these two women, they had these big log books and they had from the log book “12:01 a.m. machine didn’t work”, “12:05 a.m. fire in the power supply”, on and on it went, day after day. So after listening to that for about two or three hours Bob Evans said “Well that’s a pretty bad story, and we’ll make good on it. In fact we send a plane load of people over here tomorrow as soon as I get out of here I'm going to phone Poughkeepsie and they’ll send some people out right away and they’ll be on the plane tomorrow.” So he looks at his watch and says “Gee, today is the 4th of July, and we are closed”, and this gentleman stood up and said “You should have at least the courtesy of not mentioning the 4th of July” . With that let me close and as anybody who wants to say something ask any questions to stand up and speak. We have a few more minutes. If nobody volunteers I’ll appoint somebody, Jim.



Jim Willard: I'm not quite sure how this is going to come across since there are a few familiar faces around here, although I don’t remember you and for some reason I've lost a bit o’ hair. I lost my pipes, I still have a pocket full of pencils and bands however. How many here remember leaky transistors? Yeah there's one or two that remember. NSA remembers leaky transistors because Endicott delivered us a special purpose machine, shortly before Harvest, and it contained the early production models of the transistors, the slow versions that were used in Stretch. And nothing ever worked, and this was a machine that you had to be very careful how you programmed, it had no checking in it, but we knew what the answers were on all of our test problems and it just wasn't working. So we came up to IBM and IBM says “Well, you’ve been replacing all these transistors, why?” and IBM determined that there were leaky transistors in there, and the leaky transistors were failing. Well, you know, devices just don’t fail like vacuum--I was raised on electrostatic storage and course we always failed, you know, it's just by the manner of expectation. Which was one of my problems with Ted Codd’s project, by the way, but, you know. Ted won out because the machines became very reliable. But let me tell ya, NSA’s management was looking at what IBM was doing with those leaky transistors and we got great delivery things and we, you know, we were right into the labs with the guys who were working on the problem, and IBM solved that leaky transistor problem, and put in . . . fully installed a good set of transistors and that machine ran for many, many years after that doing the kind of problems that you can't do with anything else. And what happened as a consequence of that was Harvest and Alpha and lots of other stuff because even though it was impossible, NSA had confidence that IBM was going to come through. It may take a little longer, and it did, and they cost a little more, and Frank Carey can tell you it did, but the important thing is that we were able to have confidence that IBM was going to follow through and no matter what happened and they always did and we really appreciate what happened there.

Fran Allen will remember a Doctor Jacobs and Joe Bloom as being the people who originally started off with a concept of Alpha which she so well implemented there, and Joe Bloom died this last spring, he and Doctor Jacobs shared an office at American University in the District of Colombia, for a number of years teaching computers and software, and they enjoyed very much as one of those things that we always look forward to as what-you had been doing for the last twenty years, I’d been traveling and-and enjoying life so I will-I’ll leave it at that, thank you .



M5: I came in at the very end of the project and then went . Every machine I've ever worked on, the architecture, the instructions that were handed to me as just a , I've always wondered in the design of the hardware were programmers ever consulted ?

Harwood Kolsky: Were programmers considered? Yes of course, from the users point of view, our work was all programming. In fact, last night we were talking about this at dinner and someone brought up the example of one of the problems with employment was that the term “secretary” has been dropped from the professional list of things and that actually the secretaries were the one who ran most businesses, or at least indirectly, and I think the same thing is true the word “programmer”, the programmer took on a meaning somewhere along the line well that’s one of the people that you pay the lower pay scale to, and actually they're the ones who make the machines run, they certainly were considered. And I don’t know exactly what aspect of it you were thinking of but ...

M5: Was there input from the programmers or software designers into the architecture?

Harwod Kolsky: Yeah I was a programmer, but I’d say that as far as the people who actually studied architecture, you know, like Fred in school as a subject there weren't very many of those at that time. There was nobody being graduated from computer science departments then. But one of the things you're probably hinting at is that a system design effort should be a feedback loop, I mean you should come up with a how does this work out and how does this work out and so on, and the problem is we run out of time, somewhere along the line the schedule in the process starts saying it's too late for that, it's too late for that.

M6: Is Tom Apple here, I haven't had a chance to meet him yet if he is? Okay Tom would you be able to verify a story that I heard that if-



Eric Bloch: Who is next?



M1: When I joined IBM on the Stretch project I was a young kid fresh out of college, wet behind the ears, I bought my first suit, I think the dress codes are a little different than now but I have a question for Fred. Fred, what ever happened to that pith Helmet?



Fred: Top of the closet in the house at the beach.

Eric Bloch: Stuart?

Stu Tucker: One of my great memories, concerns will this be a six-bit or an eight-bit byte? And as I recall then we had five different design groups, the , 315, 400 and 501 and we each had to go back and say here’s what would happen if I had designed my machine with a six-bit byte or an eight-bit byte. And we all got together afterwards and my recollection is that the machines’ alternated all the way up the line as to which one was they thought was the right one or which one would be better. And I believe Fred listened to that whole thing and announced I will be back tomorrow with a decision. And we all got back tomorrow morning and Fred said very simply, “It’s an eight-bit byte, six isn’t enough for Alpha’s and for lower text.”

Fred Brooks: That’s a 360 story.

Stu Tucker: Yes.

Fred: And I must admit to having been biased by working under Werner [Buchholz] on Stretch and seeing how well eight worked.

M: Yes.

M3: Sam Slater was one of the people pushing for an eight-bit byte. He’d been working with five bits and that was stuffed up.



Eric Bloch: Carl Conti come on, you always have an opinion.



Carl Conti: Who me? Well yeah I do always have an opinion but you know I joined Stretch as a junior engineer. I would say I was probably, if not the most junior person on this whole project certainly I was one of the, out of two or three, and what no one seems to have mentioned here about this project is how it affected some of the people. As far as I’m concerned my inspiration for my life came out of the people I met out in the Harvest/Stretch project and I am just eternally grateful. So that’s not a question, it’s just a statement.

Eric Bloch: Thanks.



Casper Scalzi: I used to have a little picture I remember when we first ran the multi program. When we first ran the multi program we trialed—Fred told me about the disk and how it had a moving arm and when we would re-dispatch programs all the time the thing began to dance and shake on the chamber floor and I think after that they knew we needed a . I remember Ross Avos covered the machine and we’d just see it doing its dance on it.



Eric Bloch: Last- last comment or question. Bob?

Bob: I- I would sort of echo Carl’s comments on the- on the people thing. The thing that’ll forever be in my mind is the presentation that was given by T.C. Chen. I think alluded to T.C.’s ability, but he described lookahead on Stretch as two giraffes necking.



Eric Bloch: I think we better close down there.



Eric Bloch: Ok, I want to thank everybody, especially Fred and George Grover.

M4: Can I just ask a question?

Eric Bloch: If it’s short.

M4: I’m a little disturbed here because I hear about engineered and programmer and when did the concept of architecture come along?

Eric Bloch?: I invented it.

M4: are taking credit for the architecture which is maybe what they did back then. But to me, an engineer is someone that is given the architecture and builds a machine. Now when did architecture happen? Who is responsible for the architecture strategy?

Fred Brooks: Werner Buchholz was responsible for the architecture strategy, he was system planning manager for the project, which was the same function we would today call architecture. Werner said let’s write a book about Stretch and so in fact the book “Planning a Computer System,” of which he was the chief editor, was written and in that, in one of the chapters, I coined the term ‘architecture’ to describe what we were doing, that book didn’t appear till ’62 and we had been calling it “system planning” all the time up until then. So that’s the history of the term of the activity, the activity was going on long before there was a term and the term was just kind of drawn out of the air to distinguish it from engineering design.

Eric Bloch: Ok, that’s the end of our session this afternoon. Eric Knutsen, where is he? We’ll we assemble again at five o’clock, I think.

M6: Make it cocktail drinks, nice and clean.

Eric Bloch: That’s what I meant by re-assemble.



--------------------------------END-----------------------------




Computer History Museum

http://www.computerhistory.org
© 2002 -2004 Computer History Museum
Page of


Download 83.9 Kb.

Share with your friends:




The database is protected by copyright ©ininet.org 2024
send message

    Main page