OCRed and HTMLed by Ed Thelen
from a very poor copy provided by "anonymous" -
Click for operational characteristics of the processors for the Burroughs B5000 - 5 MByte .pdf
APRIL 9, 1979
TC-1
TABLE OF CONTENTSClick on the page number to go to that page quickly.
2
1. Introduction
There was a period during the early 1960's when remarkable technological strides were made at Burroughs. The following quote from Bill Lonergan's letter to the editor of "Computer" magazine expresses the feeling better than I have seen it done anywhere else. "Those were heady days in the computer field. It's doubtful we wilt see their like again. I wonder if the top management of any computer company today, including Burroughs, could be persuaded to proceed with a system which included as many radical departures from current design philosophy. The reward for Burroughs' gamble was a system, in the form of the B5000/5500/5700, which stayed in manufacturing fcr 10 years (probably the longest of any computer it the history of the field) and gave Burroughs a unique architectural-based position in the industry".
I was there during those "heady days". This document is an effort to capture some of the stories behind the more significant developments.
B. The compiler had to compile faster than IBM's Fortransit.
C. The time for loading the compiler and object programs had to be faster than IBM's.
D. The object programs had to run faster.
afternoon. The exact day could be determined by finding out what day that Bob left Burroughs.
III. The Summer Of 1960 (Time Spent with don knuth)
So teacher, that is how we spent the summer of 1960.
the instruction set in Character Mode better than anyone else.
************ *********** ************ * * * * * * * SCAN *-----* PARSE *-------* EMIT * * * * * * * ************ *********** ************Lloyd did not especially like the idea. so I had to figure out some way of selling it t to him. We spent several hours a day poring over the syntax chart. The separation of the three functions allowed me to think more clearly in terms of each function without the others clouding the issue. As the message from the chart began to sink into us, I realized that I had my sales pitch. So I laid it on him again and he bought it very quickly. There is no way to say that Recursive Descent is my invention or Lloyd's invention. It is simply our invention. It came to us at the same moment while we were working together in our secret room that we used to hide from the hoards of people that were always after us to explain the B5000 to them. All I am saying by the previous discussion is that this is the line of thinking that Led me to discover Recursive Descent. I am confident that Lloyd got to the same point at the same moment by a different path.
There is another sidelight to this story that has bothered me for the Last 15 years. The only hope that I have of resolving this problem is hypnosis, and I doubt that it would help either. But to be complete this part of the story has to be included.
In November, 196G I was in California waiting for Lloyd to play his game that led to him getting his $500 per month salary. There was a meeting in Washington D.C. called "The National Compiler Symposium". I was clearly the leading compiler expert in Automatic Programming because I was the only person in the group who had ever written one. So Brad MacKenzie sent me. Algol was still considered by 99% of the computing-community to be impossible to implement. I knew that it was possible to implement because Bob Barton told me so. He only forgot to tell me how.
The meeting lasted two days. The focus was on how to solve the various individual problems that were posed by Algol. Most of the papers were presented by an obnoxious group of students from
15
the University of Pennsylvania. When anyone else was presenting a paper they would laugh out loud, which clearly upset everyone else in the room. The most obnoxious of all was Peter Ingerman. The only civil member of the group was Ned Irons. and in fact he had the most interesting paper that was presented for the entire two days. It was his Recursive Assent parsing algorithm. (Of course no one called the algorithm by that name. If they had, Recursive Descent would have been 'obvious to the most casual observer). It was this group of students that coined the phrases that included the word "Thunk".
I felt like I already. knew almost everything that was said except for Ned's paper and one other. That was a paper by Or. A. A. Grau from Oak Ridge Tennessee. Frankly I did not understand one word that he said. Many years Later, after Lloyd and I had been telling the entire world that we had invented Recursive Descent, Bill Price came to me and asked when we had invented it. I told him that it. was about March, 1961. He said "Well I just ran across a paper by a guy named A. A. Grau that was presented at the National Compiler Symposium in November, 1960 and he describes Recursive Descent in great detail". So I apparently heard Recursive Descent described about five months before I "invented" it. Even though I did not understand one word that Dr. Grau said, I will always wonder what role it played in my subconscious.
Burroughs used Recursive Descent to write all of its compilers until 1969. Then a consultant named Bill MCKeeman talked to us about a compiler generation technique. All that was needed was a compiler generator and a very tight syntactical description of the language and this thing would pop out a compiler for us. He had written two PL/I-like compilers called SPL and XPL using the technique at U. C. Santa Cruz. They ran on an early version of the IBM 360. He claimed a compilation speed of 40000 lines per minute.
We could not ignore a breakthrough in technology like that. So Joel Donnelly was assigned the task of writing B6500 Fortran using McKeemans' technique. I was philosophical about it. As proud as I had been of Recursive Descent I felt that it was probably time for something better to come along.
A couple of strange things happened. First, Joel started saying that he was not comfortable with McKeemans' technique. Finally he flatly said that it would he far simpler and better to write a Recursive Decent compiler. Ben Dent felt that Joel was simply having trouble learning McKeemans' technique, so he told Joel to stick to the plan. The other thing was that I had a fellow on my project named Bob Novak. Bob was the only person in my group that knew anything about the IBM 360. I felt that my people should have the benefit of the knowledge of the new technique, so I got the listing and was describing it to them. Novak looked at the compile time and said "Wait a minute. He is not compiling 40000 Lines per minute. HP is compiling 4000 lines per minute."
16
Bob was absolutely correct. We had estimated compilation speeds of 10000 lines per minute on the B6500 using Recursive Descent. The 360 that McKeeman was using was a faster machine. So we had launched an entire compiler project it the wrong direction because we had believed in what McKeewan told us without properly questioning him. So Ben told Joel that he could go back to Recursive Descent if he wished and everybody, including Recursive Descent, lived happily ever after.
One other thing that I should clear up. I have probably left the impression that I thought that Peter Ingerman was obnoxious. Several years later, I spent a considerable amount of time with Peter working on a PL/I standardization effort. I was representing Burroughs and he was representing that colossus of the computer industry, Westinghouse. Whereas I had thought that he was obnoxious as a college student, his increasing maturity clearly demonstrated to me that first impressions are usually pretty accurate.
VII. B5000 Algol Stream Procedures
had the habit of punching holes in cards, and that is severely detrimental to a vacuum feed system.
When Dave showed up in Pasadena nearly everyone remembered him, even though it had been two summers since he had worked for Burroughs. They mostly remembered him as the fellow who would occasionally take a sharp pencil and reach 'up into the coffee machine and poke holes in the bottom of the cups. Dave always denied that he used to do that but his denials were never very convincing.
We showed Dave all of the things that we were doing, and we spent a very pleasant summer together. Dave was slow to accept the Algol Syntax Chart as a reliable tool, but he seemed to fully appreciate it, as well as all of the other interesting things that we were doing, by the end of the summer.
Then the fourth member of the group arrived. It was Fred
28
Gerbstadt. I had a private office, which was smaller that a two person office. When Fred arrived I had to share it with him. I didn't like the loss of status, or the fact that Fred was always smoking something, or the fact that Fred always invited some people in to play chess for an hour or more at lunch time.
Fred didn't like it much when I would ask him to leave the office when I received a call from my girlfriend. But he handled that pretty well. What he couldn't handle was that I had an Accutron wrist watch that I was always bragging about. I had paid $171 for it. Fred had an $8 Timex. He used to drive me nuts by secretly setting his Timex about every two hours, and whenever we would call the time-of-day to check our watches, his would be more accurate than mine.
From the day that I graduated from high school I always had a nice watch of some kind. Shortly after I received my new watch as a high school graduation gift, the face got all fogged up. I was really concerned, so I caught a bus and went downtown to the jewelers where my parents had bought the watch. The jeweler took it apart and cleaned it up for me. Then he said "I'll tell you a little secret. If it ever happens again, instead of bringing it to me, just lay it on a bare light bulb for awhile".
One day Fred came to work and he said "Damn. The face of my Timex is all fogged up". I said "Don't worry. Just take it home tonight and lay it on a bare light bulb for awhile, and the heat will drive the moisture right out". I noticed that Fred was pretty quiet for the next several days. In fact he wasn't speaking to me at all. What neither of us had taken into account is that his cheap-ass Timex was mostly plastic. The face melted down all around the hands and the strap melted clear off. I guess it smelled awful. Anyway. he just knew that I had done that on purpose to get rid of his Timex that had been the chief instrument for his favorite joke.
The fifth and last member of the group was Bobby Creech. He was known as "The fellow that Lloyd Turner used to work for, but now works for Lloyd". Bob said that Lloyd never introduced him to anyone without telling them that Bob used to be his boss at Tempco Aircraft in Dallas. Lloyd had as much trouble getting Bob to leave Dallas as we had in getting Lloyd to leave Dallas. We knew that Lloyd really wanted Bob because he always talked so highly of him. Lloyd must have done a pretty good sales job on Bob also. When we were finally introduced, Bob said to me "My gosh, after all of the stories that I've heard about you, I thought that you would have at least three heads". I was obviously very complimented.
Dave returned for a formal interview before getting his Ph.D., but I felt that it was a foregone conclusion that he couldn't resist rejoining the Algol team. Dave wouldn't give Lloyd a firm answer during the interview. I invited Dave to spend a Saturday afternoon at my place. It was a beautiful California day, so we
29
sat out or my patio in Sierra Madre and got drunk in the sunshine. Dave told me that he would love to work on the project, but he wanted $1000 per month, which was $100 per month more than I was making. I was really pleased with his admission, and I told Lloyd at the first opportunity. Lloyd asked how it would make me feel to be making less than Dave. I told him that it wouldn't bother me at all. So the rest was a formality. With Dr. David Dahm's arrival in June, 19E2, the team was assembled.
The last flowchart in my Algol Project Manual is dated 6/22/62. So that is when the design phase ended and programming began in earnest.
An unfortunate thing happened to Dave as soon as he arrived in California. Lloyd and I always tried to stay in room 101 of the Saga Motel during the four and a half months that we spent in Pasadena during the 205 Fortran project. We almost always got that room, because there was a lot of traffic noise and no one else wanted it. But we rarely ever slept anyway so it didn't bother use Besides, it was the best room in the motel for parties. Lloyd wanted the best for Dave while he was getting settled in Pasadena, so he got him a room at the Saga. I believe that it was Dave's first weekend in town that he decided to go to Hollywood Park to the horse races. All of his worldly possessions were in his room. That concerned him because he did not quite trust the people at the Saga. So he moved everything into his car and went to Hollywood Park. While he was there someone broke into his car and stole all of his worldly possessions.
My plan for writing the compiler was to write a kernel compiler in Algol, then play computer with our flowcharts and generate the object code that our eventual compiler would have generated. But that rigor did not hold up very long. I stuck to it longer than anyone else, but not all that long. We were programming in a terrible language called the Operating System Implementation Language (OSIL). Dan Brannies wrote the assembler. It ran on the 220 and generated a mess of cards that then had to be carefully arranged by hand. I think that Dave and Fred were the only ones that understood the complicated process well enough to go through it. Dave wrote some programs to help him put the mess together. If everything went, perfectly (which it rarely ever did), we could assemble the compiler in nine hours.
My area of the compiler was the scanner. It was a huge Stream Procedure with 32 parameters. carefully arranged in order. They were carefully arranged because it took one microsecond to access the first parameter: two microseconds to access the second, and so on until it took 32 microseconds to access the 32nd parameter. It was the function of the scanner to load a table called "TABLE" with strings of values representing tokens. The parsing routines would pick up the values and do their job on them. I had envisioned that the other guys would load dummy values in TABLE
30
and debug their code in parallel with my debugging. But Dave insisted that they needed their input from the real scanner, so I had practically zero time to get my stuff debugged. I felt that I was bringing the entire project to a halt.
Jack Merner and John McNeely wrote a B5000 simulator that ran on the Philco 2000. We went to San Jose to the General Electric plant to use their Philco 2000. When we had to reassemble, we would drive to Stanford and use their 220. The night shift was supposed to shut down at midnight, but Lloyd could always convince them to stay until after 1:00 A.N. When they left we would go to Stanford and reassemble. I averaged three hours of sleep a night for weeks. It was the most grueling time of my life. There was no letup when the scanner started working. Just constant pressure from Lloyd and ourselves.
Finally we got the word that the B5000 was working. But it was working so poorly that we were better off on the simulator. Even when we switched over to the B5000, the pressure continued. Finally, one glorious day, the kernel compiler compiled itself successfully and repetitively. We were free from OSIL at last. Our turnaround time dropped from nine hours to four minutes. Our progress accelerated tremendously, but the pressure was still on.
There was no time for anything outside of work but eating and sleeping, and darned little of that. We worked over 100 hours every week. One day in July, I was wanting to order some tickets for the Riverside Grand Prix which was the last weekend in October. So I asked Lloyd, in the front of the rest of the group, if I could take off one weekend in October. They all thought it was funny as hell for me to ask for a weekend off four months in advance. It was a good thing that I asked. I really felt guilty when the weekend came and I was the only one that didn't have to work.
There was especially no time for any outside relationships. My wife and son packed their bags and went to Tulsa saying that they were not coming back until I asked them to. I never asked, so after several weeks she came back and we were divorced. Lloyd and his wife were divorced the same month. She moved back to Dallas. Bobby's wife moved back to Mineola, Texas and I assumed that that were getting a divorce, but I don't think that they ever did. Fred's wife refused to believe that he could be spending that much time at the office, so she concluded that he was seeing another woman. I remember Fred, almost pleading with Lloyd to be able to spend more time at home. Lloyd said ok, but nothing changed. I think Fred's wife left him for a short while, but I'm not sure of that. Dave didn't have any relationships outside of work at the beginning of the. project. and he didn't have time to develop any during the project. By the end of the project, our families were all back together again, temporarily. Now we are all divorced except for Bobby. The reasons for the divorces were not related to the project.
31
About September, 1963 the compiler was completed. It was clearly the best compiler on earth. We were compiling a very rich language and generating good code at the rate of 1750 lines per minute. The next fastest compiler was about 400 lines per minute on a machine that was much faster than the B5000. But our compiler wasn't good enough. All of us, especially Lloyd, knew that we could do better. My pet project of writing the scanner, in a Stream Procedure had been a mistake. It caused all of our largest tables to be non-overlayable. We also knew of other improvements. So we started all ever again.
At this point, the five of us were the worlds best B5000 Algol programmers. Errors were something of the past. We literally rewrote every single Line of that compiler and debugged it, in three weeks. It was less than 6000 lines long. I wrote all six of the I/0 statement routines and the MONITOR and DUMP declarations. Remembering my American history, I called the MONITOR procedure MERRIMAC, with the comment, "THIS TIME THE MERRIMAC WILL HANDLE THE MONITOR". I am pleased to see that the name is still used in some compilers today. The six I/O routines required 900 Lines in the compiler. I believe that I had three syntax errors (keypunch errors) and one logic error. The logic error surfaced a few days later. All of my test cases ran correctly the first time. All of the other guys had similar experiences.
So we now had our "Lean and clean" compiler as Lloyd called it. So we junked the worlds best compiler it favor of a much better compiler. All of our large tables were overlayable. It would compile 2000 lines per minute and only occupied 4000 words of drum memory. The compiler could compile itself in three minutes. Stanford and other universities used to teach courses on that compiler.
The first inkling that I had that something was seriously wrong came from Bill Conlin. Bill was one of the few salesman that I had any respect for. He had made the effort and understood the B5000. Bill made same derogatory comment about the compiler. I couldn't believe my ears. So I took him to task. It turned out, that his complaint was with the MCP, and not the compiler. I had never thought that the MCP was very good, so I agreed with him. Actually, I never. thought that anything was of much value that the Algol. group didn't do. I discussed Bill's complaint with Lloyd, which started him thinking. Actually he had probably thought of this a long time before on his own. It became clear that the B5000 would never be viewed in the proper light if the ALGOL group didn't rewrite the MCP. Brad MacKenzie wouldn't hear of it. He was concerned for the feelings of the MCP group. Lloyd essentially went over Brad's head and offered his boss, Dean Holdiman, a deal. The five members of the Algol group would rewrite the MCP in our spare time (i.e. nights and weekends) if Burroughs would buy us five brand new Corvettes. They cost $5000 each. There was a period of several days. when I really thought that Burroughs was going to accept our offer. I thought that
32
Dean was fighting for it and lost.
Then along came the Burroughs head-per-track disk. It gave Brad the excuse that he needed to allow Lloyd's group to write a new MCP without hurting the feelings of the MCP group. The[y] still had their hands full with the drum MCP. Unfortunately, Dave and I had come the point that we had lost our ability to work together. We had had too many arguments to continue.
The B5000 would .have clearly failed if it were not for the disk MCP. It, in combination with B5000 Algol was a thing of beauty.
I was given the job of turning the Algol compiler over to the maintenance group while the other guys were starting the disk MCP. I still have the notes for the class that I taught, along with the time spent on each subject. The class met from 3:00 to 5:00 P.M. daily and started on October 3I, 1963. I spent 52.5 hours teaching the class. Every procedure in the compiler was covered. Our former documenter, Warren Taylor was the section manager in charge of maintenance. His project leader for Algol maintenance was John Skelton. I only recall one time that John ever came to me for help with a problem. I have never seen any statistics on the reliability of the compiler, but I have to think that it was excellent.
We were never paid one cent of overtime in any of its various forms. Brad told me that he didn't care if I didn't do anything for three months after the project was over. That is when I took up golf. So I was on the project two months before anyone else, and stayed on it six weeks after everyone else had left it.
I cannot give enough credit to Lloyd. He had a hard-headed group of angry young men to control. There was never a doubt as to who was in charge. He made every single decision himself. Lloyd Left Burroughs for a year and Bobby Creech made a very touching speech at his going away party. I wish that I could exactly recreate his words, because it captured my feelings exactly. He essentially said that Lloyd may be the most demanding taskmaster in the world. He invariably gets from his employees far more than they themselves thought that they were capable of. But in every case, when a former employee looks back on his career. he feels that the years spent with Lloyd were the most productive and in some ways, the most satisfying of his life.
We apologized for the "." being required since that was not a part of Algol. The "." did not bother him at all. He thought it was a good idea. Dave punched the program on cards for him and I showed him how to watch the SPO (a model 33 teletype) for the BOJ and EOJ. When everything was ready, Dave hit start on the card reader and B5000 went zap and it was done. Dijkstra gave a look of astonishment and said "My God. How does one get any conception of how fast it is?". I am sure that his minimum compile and execute time was two orders of magnitude slower.
So the worlds greatest computer expert returned to Europe and told his friends about the amazing B5000 Algol system. They decided to order three B5000s. We were very happy when we heard the news. However, Ray Macdonald was Vice President of the International Group at the time, and he decided that it would cost too much to set up a maintenance organization for just three machines. So he blocked the sale. Sigh.
Few Burroughs salesman understood the B5000 until it had been on the market for several years. Our current mechanism for getting a Project Development Authorization approved includes a marketing forecast. I do not believe that anything as innovative as the B5000 could possibly survive the tests that we put our new ideas through. Even if it survived the tests and. product development started, our benchmarks seem to encourage minimal thought given to the design of our software. We see benchmarks such as:
A. Successful Clear/Start.
B. BOJ for an object program.
C. Simple program compiled.
This kind of benchmarking almost demands that coding starts as early as possible. I would much rather see benchmarks such as:
A. Design of the language complete.
B. Design of the Scanner complete.
C. Design of the Statement Parsers complete.
D. Start of programming.
E. Project successfully completed.
35
Somehow I have the impression that Detroit does not feel that we have time to produce products that are superior in innovation and quality. So I can understand Lonergan's opinion that no company, including Burroughs, is likely to duplicate the feat in today's environment.
The problems that we discussed were:
E. Barton wanted more lookahead built into the architecture.
F. He wanted to do away with queues for controlling concurrent processes.
XIII. Selling The B5000 To Stanford And UTC
There were three purposes for the trip:
A. I was going to make the first of two talks at a computing seminar at Stanford.
The Burroughs salesman took us to Stanford and introduced us to
the following issue of Datamation and Burroughs received some free national publicity.
Ed Thelen says "Vera Watson McCarthy was indeed an interesting lady. The Peak Climbing Section of the Loma Prieta Chapter of the Sierra Club used to meet in her home in Los Gatos. She was very active - she had lost some friends in an avalanche in Peru, and knew the risks. The climb was Anna Purna - the book about it is 'Annapurna, a Woman's Place' by Arlene Blum."
XIV. Bob Bock's Associative Memory
adding this kind of memory to the B5000. Before he reached any conclusions, he left Burroughs.
this is the end of the type written section
Appendix A - Letter To The Editor By W. R. Lonergan
From January I959 to April 1961 I was the manager of the Burroughs Product Planning Group - consisting of approximately 20 professionals and located in Pasadena - that did the architecture of and specified the B200 and B5000 systems. Although the group was small in size, it had an extraordinary array of talent, including especially Paul King (as broadly talented a computer professional as there is in the business) and Jack Merner (a somewhat eccentric but exceptionally gifted programmer), both of whom were on my staff.
In addition, we had Donald Knuth as a consultant when he elected to get his PhD from Cal Tech and Dave Dahm as a part-time employee or consultant. Bob Burton had already been working for Burroughs as the manager of a software activity. About the time I took over responsibility for the Product Planning Group. Bob converted from an employee to a consultant-a relationship which I believe is better suited to his temperament and working style - and became a consultant to our group.
Paul King was the manager of the B5000 project within Product Planning and if the architecture of that system can be said to have evolved - and matured in any single place, it would have to be Paul King's black-board. In addition to making major contributions to the system - some of which are delineated below - Paul also provided the necessary, but unpopular filter function on Bob Barton's ideas. Like many highly creative people. Bob has some very good ideas and some not very good ideas. The trick is to use the former and reject the latter. During the design of the B5000 some of Bob's ideas made it across Paul's blackboard and some did not.
Following are some of the major innovations (at least U.S. innovations) incorporated in the B5000, along with their source and the person or persons primarily responsible for them:
Virtual memory: In May 1960 UCLA conducted a two-week seminar entitled, "Using and Exploiting Giant Computers." The program covered the IBM STRETCH computer, the Univac LARC, the Ferranti ATLAS 1 and Orion computers, the Bendix G-20, and a few other machines. The list of attendees shows that 14 people attended from IBM and seven from Univac. We sent Paul King and two design engineers from Burroughs.
Paul and I have often mused that the 14 people from IBM were apparently so wrapped up in STRETCH that they failed to rasp the significance of what the late Stan Gill was saying about the virtual memory organizations of the ATLAS I. Paul King did understand its significance and returned to Pasadena greatly excited about the concept. After a relatively brief period of review and discussion about how best. to incorporate it, a segmented virtual memory was defined into the B5000 system (its project name in Product Planning at the time was the 4000 system). The credit for this first use of a virtual memory in a U.S. machine clearly lies with Paul King, not Bob Barton.
(It is worth noting at this point that the conceptual notion of a virtual machine had by this time already been a topic of much discussion around the Burroughs Pasadena facility. I believe the notion originated with Ted Glaser earlier in the I950's. Ted was in the Pasadena engineering group from I956 to mid-1959.)
Several other B5000 design features can be traced to the May 1960 UCLA seminar. The idea of separate, modular input-output controllers can be traced to the LARC and the single number form can be traced to the G-20.
Polish notation: There is no question that the notion of producing a machine that directly operated on Polish strings and that used push down operator/operand stacks was contributed by Bob Barton, as was the notion of contextual addressing.
Algol based design: The notion of designing the system to be efficient at handling a given language- Algol - was Bob Burton's. Jack Merner, however, was our resident expert on the language and contributed most of the design ideas that made possible the execution of the concept. Donald Knuth, of course, consulted in this area.
Procedure control: Paul King came across a description of the PERIL computer built by the University of Munich. It had a highly sophisticated method of subroutine control, including allowing them to be used recursively. Paul incorporated a more generalized version of the idea in the B5000, and it became the procedure control stack. Subsequently, Jack Merrier suggested combining the two aforementioned stacks into a single stack concept, and this was done.
Character manipulation: Prior to the B5000 project (1959) there had been a 2111 computer design project in Pasadena. Under Ted Glaser's architectoral leadership the 211I was probably the most. sophisticated magnetostrictive delay line machine ever contemplated. (The project was abandoned hate in 1959, primarily as a result of the I401 announcement in October of that year.) Paul King had contributed the character string-manipulation capabilities to the 2111, and these were brought forward into the B5000. Several other B5000 innovators can be traced to the 2111. Among these are the notion of organizing the system around an exchange (we borrowed the idea from the telephone system), the notion of floating input-output channels, and the notion of ILO descriptors- (Contrary to David Bulman's note, no mention of descriptors was made with the Atlas machine.) It is difficult to attribute some of these ideas to any particular person since they developed in a design discussion group that met weekly. The group included Ted Glaser, Paul King, Don Stevens. myself, and a number of others.
Multiprocessor systems: My own awareness of multiprocessor architecture came from reading an article on another German machine, the E??56. Whether this led to the B5000 being a multiprocecessor system or whether the idea came from work done on military computers at Burroughs in Paolii is hard to say. Certainly the Paoli group contributed the notion of a conflict-resolving, switching-interlock system.
As can be seen from the above, the B5000 had a rich and varied ancestry. It certainly affirms the notion that good system architecture includes a lot of intelligent plagiarizing. The design of the B5000 system - like the design of any computer system - involves a number of major architectural contributions and hundreds of less major, but nonetheless significant, design contributions, sometimes involving the use of a single bit. Unfortunately, space does not permit mentioning all those who contributed or what they contributed. (I hereby ask some of my old friends to understand.)
The purpose of this letter is not to minimize the contribution of Bob Barton to the B5000 or to computer architecture in general. Rather. it is to place those contributions in perspective and to acknowledge that a number of other people - some not even mentioned in this letter - made significant contributions to the B5000. The total contribution of Paul King, in particular, was probably at least equal to that of Bob Barton.
Although the writer participated in many architectural and design sessions, he makes no direct claim to any of the major innovations in the B5000. I do, however, claim that I played the primary role in persuading the then pre-Ray MacDonald top management of Burroughs to proceed with and announce the system. Those were heady days in the computer field. It's doubtful we will see their like again. I wonder if the top management of any computer company today, including Burroughs, could be persuaded to proceed with a system which included as many radical departures from current design philosophy. The reward for Burroughs gamble was a system. in the form of the B5000;5500;5700, which stayed in manufacturing for 10 years (probably the longest of any computer in the history of the field) and gave Burroughs a unique architectural-based position in the industry.
As a final point, it is worth noting that since my memory is no better than most, I refreshed it by rereading a fair array of detailed design notes and material that exists from the period under discussion.
Bulman replies
Editor,
As a result, there is little substantial disagreement between my outline of the project and Mr. Lonergan's letter. Much of the apparent disagreement lies in the distinction which should be made between computer architecture and product definition. There is little doubt that many people contributed heavily to the definition of the B5000 as a product, including many in the Product Planning Group under Mr. Lonergan.
It is interesting to note that, as early as the summer of 1958. while working at Shell Research, Barton brought forward the idea that main storage should be allocated automatically by the hardware, rather than have the programmer concern himself with overlays from secondary memory. This certainly adds plausibility to the statements of essentially everyone else on the project that Barton was responsible for its virtual memory.
Another important idea of computer architecture is the use of the hardware stack for computational history (called procedure control in the letter). All the people from the project I talked with attribute most of this to Barton, with very significant contributions from Jack Merner. In addition to combining the two stacks, the much more important method of handling parameters called by name was invented by Merner.
I fervently agree with Mr. Lonergan that many other people contributed significantly to the success of the B5000 project. I only wish that I had been involved, so that I could share more deeply the amusement felt by those on the project. as they watch the features of their circa 1961 computer gradually being introduced by the major computer vendors of 1977.
Reprinted from the Communications OF THE Association FOR COMPUTING MACHINERY Volume 4, Number 9, September 1961 Made in U.S.A. A Syntactical Chart of ALGOL 60 WARREN TAYLOR, LLOYD TURNER, AND RICHARD WAYCHOFF Burroughs Corporation, Pasadena, California .I don't know the copyright status of this document,
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4