An Interview with Bob Hughes

Bob Hughes

BH = Bob Hughes
GAM = George Michael

GAM: It's May 9, 1997, and we are interviewing Bob Hughes. Bob, can you start by saying when you got to the Laboratory and where you came from?

BH: OK. I graduated from high school in 1944, during World War II, and was immediately drafted into the United States Army. I pretty much had to sit out the war, basic training and that sort of thing. When I left the military service in 1946, it was difficult getting into college, especially the top schools, if you didn't have an "A" average or something of that nature. Because of the GI Bill, there was a big rush for enrollment. Finally, I was accepted at Duquesne University in Pittsburgh, Pennsylvania, as a freshman. The next year, I transferred to Western Reserve University in Cleveland where I recieved my BS degree in 1949 or 1950. After Western Reserve, I worked on my Masters at the University of Michigan for a year. They had a one-year Masters program there. I finished that year and I ran out of money and the GI Bill, so I decided to visit a friend from the army who lived in Oakland. I came out and bummed off him for a while until I got a job. I worked at odd jobs like at the Post Office. And one day, a friend of mine, Bob Abbott, told me about Lawrence Livermore Laboratory where he'd just begun to work. I asked him what he did and he said he was programming a computer and I said, "Well, come up to my apartment and tell me what you do and how you do it". I looked at it and I said, "Well, I could do that".

GAM: What year was this?

BH: This would be 1954. That's when I was hired. But I came to California in September of 1951. I came to California straight from the University of Michigan. And I'd been here for three or four years or so, but I couldn't find a meaningful job. Outside of a letter carrier or working with people unloading a truck or something. So, finally, I heard about the Lawrence Livermore Laboratory though Bob Abbott and I went to the University of California for an interview and the person was impressed with my mathematics. I had a pretty much an "A" average in math, or close to it. But, anyway, within three weeks I was invited to Livermore by Doctor Sidney Fernbach to join his group.

GAM: Great. What was your first job?

BH: Well, when I got my security clearance after about two months, I went up to see Doctor Fernbach and said, "Here I am, what do you want me to do?" And, in a classic way of assigning things in those days, he said, "Well, just walk down the hall and find something to do." I ran into a group of Physicists and they asked me if I would be interested in working on a Monte Carlo simulation.

GAM: Whom did you talk to?

BH: It was a group of three Physicists headed by Ed Leshan. I forget who the other two were.

GAM: Was Art Biehl was one of them?.

BH: That may be. The name doesn't ring a bell, though. But, anyway they said, "We need a computer program to build a Monte Carlo neutron transport simulation. Do you think you'd be interested in something like that?" I said, "Sure". I went back to my office and said, "Well, Hughes, you've really gotten yourself into trouble now because you've got to admit that you didn't understand a word that man said." But then, I thought for a few minutes and said, "Now, wait a minute, Monte Carlo. Monte Carlo. Oh, that's a gambling town, statistics; oh, this is the statistical methods for determining the outcome of an event, you know. I thought about it a while and I went back to talk about this further, and they had all the equations set up and things I might need to turn this into a computer program. So, I guess the moral is, if anybody asks you if you can do something, always say "Yes".

BH: So, I set up a Monte Carlo program for them. And, later on, I also set up a novel way of handling neutron cross sections. I'd write out a cross-section file from the data on IBM cards, and I would use that to compute the probabilities that a neutron would go a distance "Delta X" through a region containing some material "Y". It's based on an initial configuration but, anyway, it was a fascinating experience and it went into production. That was for the IBM 701, which was hand coded for the machine, and when the IBM 704 came out it was still a production code, but now we could write it in FORTRAN. Later, as you know, we were short of computer time at the Lab. And so, one summer, IBM decided they could sell us a block of time if we were willing to take the 12 midnight to 6 o'clock in the morning shift to do our work. So, I was sent to New York, and that's how I gained experience on the 704. We had one too, of course, but I was sent to New York, several times. I had to go back to run this Monte Carlo problem for the group of physicists at the Laboratory. One interesting thing happened: One night, I was given the whole time from midnight to five in the morning. Since I could run this problem anytime I wanted to, I had it set up as a production run; where someone else could just run the problem for me. So, this one night, I got a call from the engineers that the IBM 704 had stopped while my program was executing. I went in and found that there was some sort of a malfunction which caused the green "Run" light to be on at the same time that the red "Stop" light was on. This implied that the machine was both running and stopped at the same time. It made no difference to me because my problem was producing good answers. I ignored the condition. But I was called the next morning about 7 o'clock by a vice-president from IBM saying, "We have a problem here with your usage." I don't know how much they were charging me an hour maybe $100 or $200 an hour. But, anyway, I had used about $6000 for computer time. And they were wondering why this program showed it was hung from 3:00 AM and now who was going to pay for this three or four hours of computer time? I said, "Well my program worked. What's the problem?" They said, "We don't know yet, our engineers are working on it." It turned out that a problem in the IBM 704 logic design, under certain conditions, if they failed to clear the MQ (multiply-quotient) register, the accumulator got bad data. If the MQ is not cleared, then you would end up with the machine stopping, and the red light on saying "I'm stopped" and green light on saying, "I'm running." I asked the vice-president, "Have you been able to find anyplace in your documentation where it says that MQ has to be cleared?" He says, "That's just the problem, we can't find it anywhere. I've called up our designers in Hartford, Connecticut and Chicago, but we can't find it, it's not documented." So I was off the hook.

GAM: But, it wasn't your responsibility to clear it anyway.

BH: It was a flaw. They could have put a chip or something in there to clear the MQ, but it turned out to be an oversight. They did write it in later on. But, at the time, he said, "I can't charge you because it's not documented." And my heart went back to beating at the normal rate. So, that's how I got to learn the IBM 704.

GAM: This has to be the years 1954 and 1955. And around 1956, you got involved with the FORTRAN Project?

BH: We got wind of the FORTRAN Project late in 1955. Dr. Fernbach came into my office and said that John Backus was amenable to having someone from the Lab come to work with him. So, he asked me if I would go and, as usual, if you don't know how to do something, you say, "Yes."

GAM: That's great. That was a career-enhancing assignment. That's a really important thing.

BH: That's right. It's amazing how fast you learn what's going on. In less than three or four months, with the FORTRAN development group, I became a confirmed compiler advocate.

Well, I say that rather than rambling around, I started at the Laboratory on my birthday, which was February 23, 1954. I retired on my birthday, February 23, 1987, for an even 34 years at the Laboratory. And, as I mentioned, the UNIVAC 1 was still in operation when I started, but I didn't get to work on it. It was the first large-scale digital computer of the stored-program type. But the new 701, IBM's first machine, was taking over due to its superior speed and larger memory.

GAM: It may have been faster, but it kept making errors all the time.

BH: True, you know, the UNIVAC had those duplicated Mercury delay lines, and they checked everything. Nothing was checked in the 701.

GAM: Yes, the UNIVACdid a periodic memory check every second.

BH: Yes, you fetched the same item from two different places and compared the results. They had to agree or the machine stoped.

GAM: Yes, but on the 701, there was no checking.

BH: That's known as the single fault error checking chain.

My first job was to develop that Monte Carlo physics code for the 701.

GAM: When you went to the FORTRAN project, did you have a specific assignment or was it just to go back there and tell them about the kind large codes we were developing?

BH: No, no, no. Each person in the FORTRAN development group had a specific assignment. Holland Herrick, for example, was in charge of all tape I/O; that was his baby. To backtrack, FORTRAN was a table driven scheme.
Bob Hughes

GAM: Oh?

BH: Many tables. TEIFNO was a typical table of IF and GOTO entries. "TEIFNO" stood for the Table of External Form of the IF Number versus its internal form. There were also "close-up" tables to close everything when finished. There were just tables, tables, tables. Later on, they discovered that the way to compile really fast was to collect everything and assemble it in a single symbol table. But, in those days, we were still learning how to walk and so, initially, it was a table-driven scheme.

One person, Peter Sheridan, had the responsibility for parsing the computer's mathematical equation-generating instructions. That was one of the most important areas of the whole code. And so, in that fashion, each person was responsible for a specific part of the compiler. Roy Nutt, in Hartford, Connecticut, handled all the formatted I/O. He was head of the computing group in Hartford. He took care of all of the background work involving I/O and input/output statements. And so, each person had a hunk of the compiler. When I first got there, I noticed that IBM used the closed-shop technique. You programmed, but you didn't have to see a computer. If you had a problem to run, you would submit your deck and take your turn. You'd come back in the morning and the listings would be on your desk. And that's the way you worked.

BH: I'm forgetting my point here. Everybody had a specific task. And they knew that I was unfamiliar with their schemes, so they would just hand me the code listings. They'd say "Herrick has this problem and we need a flow chart for that". I would read his machine language code and turn it into a flow chart. Then we could see errors and we could make changes to the program. So, now he has something that will serve him as a programming aid without wasting his time chasing around randomly. I worked on what they called the "first-level" documentation. And I made the biggest mistake of my life by not bringing a copy of that home. Now you understand why I missed making my first million dollars.

GAM: Most of us are still working on that, don't worry about it.

BH: Each person was assigned to a major section of the compiler and each person had his own set of tables to work with. And I would put the pieces together and then, somewhere along the line, there was what we call a "Semantics Synthesizer", where it all comes together into a machine language code that would run on the machine. It was a fascinating experience.

GAM: It must have been exciting too.

BH: Oh, it was. They were the nicest group of people you've ever met, all of them. If a computer conference was being held in Washington, D.C., then IBM would notify us and send the whole group to the conference and we'd come back and continue working. It was quite an experience.

GAM: Well that's great. And when you got back from IBM?

BH: I should mention that, one day, John Backus, the head of the group, called me into his office and said he'd like to get my ideas of what I thought of the project. About FORTRAN and in general. I said that, "Well, there�s one thing that I worry about; you're only putting out a main program. There are no user-defined subprograms. At the Lawrence Livermore Laboratory," I said, "there's some programs with many sub-programs, but you're just putting out a main code. You're allowing for system functions like square roots and science and trigonometric functions, and so on. but we use lots of user defined sub programs, and also, you're assuming that the program can be memory contained but, we almost never get the memory contained with the big problems at Livermore, so we use a program design that can be chewed up into modules. Actually, we almost never get the memory contained with the big problems at Livermore. He said, "Well, I understand that but, in this particular case, I want to prove first that a computer can generate good code, and that a compiler can be written to generate a good program that rivals the efficiency that the hand programmer can produce." And he said, "That's going to be the important thing, I think you can lay it right there." He said, "Then we can get together later on and add all the other factors that need to be added in to make it even more convenient. But, I've got to get over that first hurdle to demonstrate that the compiler can generate good code, and of course, he was right.

GAM: Also, on your first swing back there, you started the idea that if a variable's name began with i, j, k, l, m or n, it's an integer.

BH: Yes, and for all other letters, it was a floating point quantity by default. Well, later on and when we started doing our own compilers, all those features were added. Different groups came up with different ideas when produced the second version of FORTRAN. I think even IBM allowed you to override the i, j, k, l, m, n convention.

GAM: Not at first.

BH: Not at first? OK. And that's what LRLTRAN at Livermore was all about.

GAM: That's one of the things.

BH: Another was mixed-mode arithmetic. In the first FORTRAN, you couldn't do mixed-mode arithmetic. An expression had to evaluate to be a real or an integer. We got around those hurdles by allowing the programmer to declare any main variable to be integer or real. There was quite a bit of awkwardness in the original FORTRAN. Using numbers for statement numbers. You had to number your statements, as opposed to allowing alphanumeric statement numbers. There were a number of other embellishments, such as IF-THEN-ELSE logic, In the 1970's, structured programs tried to avoid the use of statement labels. I don't know if the IF-THEN-ELSE logic was ever put into the IBM FORTRAN. We put it into ours.

GAM: I think an early real mistake in their first FORTAN, which induced us to have bad habits, was the three-way branching IF statement. That wasn't very good.

BH: Oh, sure. Then they introduced IFs where you could have two branches. Less than or greater than.

GAM: Well, true or false.

BH: Yes, it was a logical step.

GAM: So, when you came back, having worked through this development of FORTRAN and stuff like that, were you the Lab's missionary for FORTRAN then, or did you just go back to writing Applied Physics Codes?

BH: No, that got me into the language game. When I got back, there was a lot of excitement. I got into a Language Group with Kent Elsworth and Dorothy Monk. With my experience in FORTRAN, they formed the K3 Compiler Group. We had the three-line input, whereby you could put the variable on the middle line and the superscripts and subscripts on the line above and the line below to make it look more like a mathematical language. Believe it or not, after a year and a half or so, we actually got the thing running, but I don't think anyone ever used it.

GAM: It was very hard, I tried to use it for my code. You had to get everything in the right column all the time. That is what was wrong.

BH: Yes, you had to worry about getting everything exactly aligned, and that was a losing proposition from the start. For a while, there was fear that mathematicians would not accept standard FORTRAN. For example, A**B means A to the B power because we didn't have any way to keypunch AB.

GAM: That's a big concession to the IBM keypunch symbol table. They didn't even have anything like a square root.

BH: Yes, this was all invented.

GAM: Invented to get around the IBM keypunch?

BH: But there were a lot of efforts.

GAM: So, you worked with Kent on what he called the Kompiler.

BH: Right, we called it the K-O-M-P-I-L-E-R, Kompiler. But it became the world's second "Spruce Goose".

GAM: How do you mean "Spruce Goose"?

BH: It taxied well, but it never took off.

GAM: Well, we tried to use it, but that input deck was so voluminous. Basically it was three times the size it should be.

BH: Oh yes, in those days. Yes, it took three cards per line. That was another problem. If we�d had display tubes, or something like that, where you didn't have to worry about punch card data, it may have run.

Let's see, in 1960, I did another Physics code for the Remmington Rand LARC (the Livermore Automatic Research Computer), and I forget what that was all about. I began doing systems programming on the LARC, our last decimal machine. The Remington Rand-UNIVAC division, built it for us, and I did some systems programming on it. I probably converted one of the physics codes I already had to run on the LARC, either because of FORTRAN or it being an extra big problem. And I started a special systems program for the LARC to go between decimal and binary formats. The decimal representation, for a digit, in the LARC took much more room than it did in an IBM computer and therefore, their tape drives ran much slower than IBM tape drives. So we decided to fix it so the LARC could use IBM binary formatted tapes.

GAM: Yes, I remember that.

BH: Well, Jim Moore, the electrical engineer in charge, was assigned the job of rewiring the LARC tape handler. They rewired the tape synchronizer, and then I had to write the software for converting the binary data on the tape to the decimal format that the LARC wanted. But that way, we got the benefit of high-speed IBM tape drives running on a decimal machine.

GAM: So, you had to write the tape handling routines for the LARC?

BH: It was what they called the I/O processor, the part of the LARC that managed all the I/O processes. The I/O commands that the programmer issued were re-interpreted by my software. Not from the programmer's point of view, but the electronic signals that came in had to be mapped.

When the Lab decided to buy the STRETCH machine, Dr. Fernbach had me do a benchmark because IBM had announced that the STRETCH would be 10 times faster than brand X. And so my job was to take a program that was running on the LARC and set it up to run on the STRETCH. I did that and published the test results and gave them to Dr. Fernbach. It turned out that the STRETCH wasn't 10 times faster than brand X; it was barely a factor of two. So, in negotiating with IBM, the STRETCH price was cut quite a bit.

GAM: Yes, I remember they couldn't meet their own specifications. Sid tried to cancel the contract and to avoid that, IBM cut the price; something like 48%. Actually, they made a lot of money on the components that they developed for STRETCH and used in the 7094 and the 1401 sustems, and still they could charge all the STRETCH costs off as tax losses.

BH: That all happened around 1960. Then, about 1965, Sam Mendicino, George Sutherland, and others were working on compilers for the Control Data machines. They came up with the first compiler compiler. And so we really got going big and got to work on our own FORTRAN compiler. We never did use the manufacturer's compilers. Well, they were there, some people did but, from day one, we focused on developing our own FORTRAN.

So, from there on in, I sort of gravitated into the language end of the business, strictly compilers. But I did a lot of other things along the way. In the 1970s, the UC business group that handled the Lab's administrative computing, moved to the Lab. And they wanted COBOL, so Pat Gray asked me to modify one of the existing LRLTRAN compilers to accept and produce COBOL, I think that's when he became a division leader, and he was trying to satisfy that group. I don't know how far that got, but I rewrote the front-end of our FORTRAN compiler to read the COBOL Language.
Bob Hughes

GAM: Would you say that was your most exciting period then, when you worked on our FORTRAN?

BH: Oh Yes, it was fascinating, because we knew everything about everything.

GAM: Oh, I understand. It's a nice thing to have the big picture.

BH: It's nicer to be a big duck in a little pond, than a little duck in a big pond. The pond got pretty big later on.

GAM: And it's not stopped growing yet.

BH: But it was fascinating. Actually fascinating to me. Because it was always a challenge. There was always a better way of doing things. It was never boring. Sometimes you'd wake up in the middle of the night and you'd want to run out to the Lab and start work on this new great idea you had.

GAM: Yes, I've done that.

BH: But I also worked on assemblers in the old days. Matter of fact, I wrote an assembler for Dr. Von Holdt. After everyone had turned to FORTRAN, he still used my old assembler. And I had one of the first text alteration routines.

GAM: I thought that was a great thing.

BH: Yes? Well, the Alter would allow you to make modifications to the existing program. This was a simulated program. You referred to things by line number. You know, do you want commas here, delete lines one through three, replace it with the following lines in here until you see a card marked such and such.

GAM: I made very heavy use of that.

BH: It also made changes in your program, sort of a poor man's text editor. And it also put out a relocateable binary module that you could load back into your program. But then we really got to going strong. We got to the point where we were all LRLTRAN/FORTRAN and had our own compiler group set up. But I've worked on just about every compiler after they came along from the time I started at the Laboratory.

Let's see, Sam Mendicino and George Sutherland did the first bootstrap. You know FORTRAN/FORTRAN. They used FORTRAN to write a FORTRAN file.

BH: And that was a Godsend. The program meant that there were no more single language programs.

GAM: It grew into LRLTRAN eventually, didn't it?

BH: Yes. That's what I mentioned, at that point around 1965 onward we were sort of on our own. We had our own language, our own version of FORTRAN. We were compatible with standard FORTRAN and still had special features for the Lab.

GAM: I don't remember that. I remember for instance, you guys had something about the Divide that you rounded before it was completed or you didn't put it in the hierarchy of operations in the right place or something.

BH: Well, you'll probably find that in all the conversion estimates, whether or not you round or not. You probably will find that that's a problem that won't go away. In one part of the country they are rounding in some instance, in another part of the country they are not rounding in this case. That's just an incompatibility in the numbering base. For one thing, that's in the binary and when you chop a binary bit that's one-fourth of a decimal digit maybe.

GAM: Right, I agree with that. I thought that it was very important that all the FORTRAN's had the same behavior.

BH: Well, the different machine word sizes tie you up.

GAM: I guess I understand that.

BH: It's another problem beyond the size of memory.

GAM: There was this guy from England, Pyle, who designed these "Encode and Decode" statements that re-adjusted the formats so that you could move iotems from one to the other and back pretty easily.

BH: Well, in the division in each machine you're going to end up with a non-terminating decimal fraction someplace along the line when you get past the integer, past the decimal point. Wherever you chop there's an error, so a given specific rounding procedure isn't going to be any help. I mean the problem's not going to go away.

GAM: With all this programming, you found time to become a golf expert too?

BH: Oh yes, in my spare time. In those days, I would only golf on the weekends, once a week maybe on Saturdays if I could afford the time or maybe on Sunday or a day off, or vacation; things like that. I never was a "leave my work to go play golf" type. I was not that much of a fan. But, as the years went on, it turned out to be the most fascinating thing in the world. Golf wasn't as popular in those days as it is now.

GAM: But in those days you thought about how you might use computer programming to interact with the game?

BH: No, but in those days, when you're young you just stop off on the way home from work. You think, "I'll just play 9 holes on the way home. You then get home late and stay up half the night. It's a fascinating sport, I love to play it, and always will. I started playing golf around 1962.

GAM: OK. Did you have anything to do with the STAR?

BH: That was the Control Data STAR, the vector machine, right?

GAM: Yes.

BH: That was sort of a turning point for me. I sort of got out of the compiler business for a month or so and I started working with the System Utility Group for the STAR. Harry Nelson was benchmarking the STAR and had done a lot of work. I guess he was in charge of the system development there. He came by my house one day and said he needed a utility for comparing two files, which was a big thing in the computer world. He wanted to make sure the file they had been keeping around had not changed. He was interested in getting an efficient code, as opposed to saying "fetch word one, subtract word two, and record the result". Since the STAR was a vector machine where you could refer to an entire array with one instruction, there should be some very efficient ways to do comparisons. He wanted me to find out if there was some keen or slick way. After a week or so of playing around and thinking things out, I finally looked at the HEX FF instruction which was designed to tell you where a subset occurred within a larger set. I said, "Well, if I make the subset as big as the set, I can compare two files very fast." What an instruction. It would only tell you that the files did match. If they didn't, it didn't tell you where the mismatch was. But that was half the battle because, most of the time, you were only interested in knowing that nothing had changed. So I hedged that bet. But, if you wanted to find out where, then it was not efficient. Then you had to look at it one word at a time to get down to the point where it had failed. And then look to where you could fix it if you wanted to move ahead.

GAM: Well, you use all the methods that you need.

BH: I was happy about that. I got a one-word program. So, I managed to get involved somehow with all the machines that came along. But I didn't do any programming on the STAR; I just worked applications while I was there.

GAM: How about the STRETCH? Did you work on the STRETCH?

BH: Yes, I worked on the STRETCH, in 1965 we did an LRLTRAN FORTRAN compiler developed on the LARC and STRETCH for the Control Data 6600. What we were doing was preparing a compiler for the new machine that was coming in. I think that was one of the first FORTRAN-to-FORTRAN bootstraps that came along. I know that Sam Mendicino had a lot to do with that, and I was working with Sam at the time.

GAM: OK, that's great. What else do you have?

BH: Well, John Ranelletti and I were office mates for years. In the 1960s and 1970s we were always office mates. As a matter of fact, going back to the 1950s. After I left the K3 compiler group and FORTRAN came along, I would work with John Ranelletti and Sam Mendicino in the old Navy barracks building where we had offices. Sam Mendicino, John Ranelletti and I were always in the same office. And we worked generally on the same things including the first bootstrap, Sam was in charge of that first bootstrap.

So, by hook or by crook, I got involved with just about every computer that came through the door, in some capacity or another.

GAM: Did you ever develop an opinion for which computer you liked the best?

BH: I think the computer I liked the best was the Control Data 6600 or the 7600.

GAM: That's pretty much a general reaction.

BH: I loved the assembly language. The instructions that you used didn't need addresses. That was a Seymour Cray invention. Like A, I, J, K. You referred to registers. If you wanted to store the operand, it had to be in the correct register; the register which had the pipe to the memory. You would say, multiply register 1 by register 2 and put the result in register 3. It was likely stored in memory depending on how you indexed. It was easy to understand. Matter of fact, I wrote an assembler for the 6600.

GAM: What else did you work on?

BH: I guess the other item I got involved in was the Summer Institute, as the technical coordinator for some visiting professors during the summers. I was involved with this from 1975 through 1979.

I served as the affirmative action coordinator for the Livermore Computer Center, and I got involved with documentation/education group. I call that a low point because I got out of touch with reality at that point.

GAM: Well, it's certainly different in the sense that here you are confronting people from a different discipline who are trying to learn something about what is going on at the Lab. That's a nice opportunity.

BH: No, no, I didn't mean the Summer Institute. No, that was great. That was interesting. I was referring to the documentation/education group. And that part didn't pan out too well. I was in a no man's land. You don't know what to do. Or you don't know how to do what it is that you want to do. The Summer Institute was fascinating, and it didn't cost us much time.

GAM: It was useful letting the visitors learn about things they they ordinarily run into in their schools.

BH: Well, that was part of the affirmative action program. Allowing the visiting professors from predominately minority and female institutions to spend time at the Laboratory and getting to participate in ongoing research. I would take them all around to the various departments and special seminars.

GAM: Great! Thanks, Bob, for taking the time to share your memories with me. Your Lab career has certainly been fascinating.