by Kurt W Beyer
In the months that followed the presentation of Ridgway’s paper, the Computation Analysis Laboratory addressed the problem of compiler efficiency. Hopper admitted that the A-0 compiler, despite its inherent logic, was cumbersome to use.30 For instance, if the A-0 was processing a subroutine and that subroutine required transfer of control to another subroutine, the A-0 did not know where the second subroutine began. This forced the compiler to transfer control from the first subroutine to a temporary storage location while keeping track of the fact that a control transfer to the unprocessed subroutine was still necessary. Since a programmer could create a flow chart of the entire program before coding, such intermediate steps could be avoided.
The group’s research efforts were rewarded in the early winter of 1953. The A-1 compiler was completed and tested by January, and much of the cumbersomeness of A-0 had been refined and eliminated. By the spring of 1953, an even cleaner compiler, the A-2, was developed by Margaret Harper, Frank Delaney, Mildred Koss, James McGarvey, and Richard Ridgway under the direction of Herbert Mitchell and Richard Woltman. Hopper had recruited Mitchell and Woltman from the Harvard Computation Laboratory and felt comfortable turning over the day-to-day project management of compiler development to them.31
A closer look at the manual for the A-2 compiler (produced by the Computation Analysis Laboratory during the summer of 1953) suggests that, despite the significant improvements over the A-0 compiler, automatic programming had its limitations. Hopper’s vision of intuitive, user-friendly, hardware-independent pseudo-codes generating efficient running programs was far from realization. The A-2 provided a three-address “pseudo-code” specifically designed for the UNIVAC I 12-character standards. The manual defined “pseudo-code” as “computer words other than the machine (C-10) code, designed with regard to facilitating communications between programmer and computer.”32 Today we refer to it as source code. Since pseudo-code could not be directly executed by the UNIVAC I, the A-2 compiler included a translator routine which converted the pseudo-code into machine code. (See table 8.3.)
The manual states that the pseudo-code is “a new language which is easier to learn and much shorter and quicker to write.”33
TABLE 8.3
Examples of pseudo-codes from the A-2 compiler subroutine library.
Add AA0004 F00001 Logarithm LAU118 F00001
Subtract AS0004 F00001 Root RNA154 F00001
Multiply AM0004 F00001 Exponential X+A096 F00001
Divide AD0004 F00001 Change sign AN1002 F00001
Cosine TC0100 F00001 Input generator GMI000 F00001
Sine TS0106 F00001 Test QZ0004 F00001
Arctan TAT118 F00001 Type in BTI002 F00001
Raise to a power APN048 F00001 Print out YT0004 F00001
Indeed, it was easier compared to manually writing machine code. If the user wanted to solve for the cosine of a, for instance, she would look up the appropriate pseudo-code in the subroutine library catalogue.
The familiar notation
y = cosa
was written
TCO(A) 000(Y).
Note that the pseudo-code call-words conformed to UNIVAC I’s twelve-character structure, with parentheses in the first example signifying the relative working storage address of the quantity called for. In most cases the second character correlated with the subroutine operation it depicted, such as S for sine and M for multiply. But Hopper admitted years later that her team, at the time, could not see very far past the constraints of the UNIVAC hardware:
I think we often forget how much our surroundings influence our research decisions. All those things that we’re aware of and yet are not aware of when we make decisions. And the fact was that we were living in an environment which consisted of a 12 alpha-decimal word, and it became perfectly obvious to us that the entire world operated in 12 alpha-decimal characters of which the first three defined an operation, the next three one input, the next three another input, and the last three the result.34
Despite the limitations of A-2 pseudo-code, Hopper and her team incorporated innovations that made the compiler more user-friendly. Unlike the A-0, the A-2 now made two sweeps of the pseudo-code. The first pass generated a record to help the compiler make more efficient code on the second pass. The record, which was a list of operations, could also be printed out and serve as a general check of the compilation before the final running program was completed. Normal printouts during compiling, such as “end translation,” “end sweep 1,” and “end compile,” informed the user about the stage of the process. The most groundbreaking change was the A-2’s ability to debug pseudo-code and flag errors automatically. The compiler generated twelve-character error codes that captured the nature of the error, a miraculous innovation for any programmer who had experienced the pain and monotony of debugging computer code. (See table 8.4.)
Although the A-2 compiler had been designed for novice programmers, Hopper understood that in order for it to be more widely adopted her team would have to add features that would be appreciated by skilled programmers. The A-2 made it easier to modify compiled programs. Entrances, exits, and references to working storage could be manipulated manually, thus allowing parts of a program to be reused with other operands in another section of the run program. For instance, if the A-2 generated the same subroutine in two different segments of the run program, a skilled programmer could now remove one, producing a more efficient final run program. Furthermore, modifying programs was easier, and changes could be made without the need to restructure the entire routine.35
TABLE 8.4
Examples of error messages generated by A-2 compiler.
RINFOΔ WORD?R A word of information fails tests: transcription error.
RTΔMCH ΔINFOR The compiler can store no more than 60 descriptive words: memory exceeded.
RNOTΔI NΔLIBR The word of information is a call word for a subroutine not in the library.
RFULLΔ TAPEΔR The 1955 data blocks on the running tape have been used.
ROPΔSE QΔOUTR The information lists an operation number that is not in the proper sequence.
RNOTΔS TOREDΔ The programmer called for a generative routine that is not in the library.
COMPILING ROUTINES
In the May 1953 issue of Computers and Automation, Grace Hopper heralded the laboratory’s successes in an article titled “Compiling Routines.” She predicted that the next generation of compilers, coupled with efficient subroutines that had been tested and proved, would produce machine code as efficiently as the average programmer. Subsequent tests had shown that “the reduction in programming time for those classes of problems upon which compilers have been tested is incredible, actually little short of fantastic.” Nonetheless, Hopper reminded the programming community that these compilers were still in the prototype stage, with limited availability of tested subroutine libraries.”36
Hopper focused attention on another major benefit of compilers: pseudo-code. Pseudo-code freed the user from the constraints of the machine’s hardware, for the compiler, not the user, was responsible for changing the pseudo-code into machine-specific code that the computer could process. In her first paper she had focused on the time benefits for the mathematician/programmer, but by the time of the May 1953 paper Hopper had realized that pseudo-code exhibited two revolutionary attributes.
First, the designer of the compiler now was a linguist. That is, the compiler programmer had the ability to design the syntax of the pseudo-code. Hopper noted that for mathematical problems this was comparatively easy to do, since mathematical symbolism had become standardized over the years. Therefore, a compiler designer could have the pseudo-code match accepted mathematical terms: cos, add, sin, exp, and so on. Hopper emphasized that what was relatively straightforward for mathematical pseudo-code was problematic for the pseudo-code of other imagined commercial compilers. For example, a logical, intuitive pseudo-code would have to be planned out and standardized for accounting and payroll compilers. “If ‘cos’ indicates cosine,�
�� Hopper writes, “why not use ‘foa’ for ‘federal old age’ or ‘ssd’ for social security deduction?”37A well-constructed pseudo-code had the potential to make computers available to users other than programmers and mathematicians. Not only would it be far easier to learn than machine code; its intuitive logic would help users debug their work. “I felt,” Hopper recalled, “that sooner or later . . . our attitude should be not that people should have to learn how to code for the computer but rather the computer should learn how to respond to people because I figured we weren’t going to teach the whole population of the United States how to write computer code, and that therefore there had to be an interface built that would accept things which were people-oriented and then use the computer to translate to machine code.”38
The second benefit of pseudo-code, program portability, would have far more meaningful ramifications for the future, though it appears that at the time the article was written Hopper thought of the benefit more as a nicety. She mentioned that compilers could be designed to program the machine code of any computer. “A problem stated in a basic pseudo-code can thus be prepared for running on one or more computers if the corresponding compiler and subroutine library is available,” she wrote. Just as the compiler freed the user from knowing how to program in machine language, pseudo-code was now liberated from a specific type of hardware. A payroll pseudo-code could run on a UNIVAC or an IBM computer, so long as the appropriate compiler was running on both. Hopper stated that as of May 1952 such a benefit was theoretical, insofar as her laboratory had tried it only once, with inconclusive results.39
In the same article, Hopper compared compilers to another example of “automatic programming” that had gained momentum since her “Education of a Computer” presentation: the interpreter. An interpreter is a program that executes a pseudo-code much like a compiler. The difference lies in the output of the execution. Whereas a compiler generates a program, an interpreter “interprets” a pseudo-code that refers to a subroutine and immediately performs the subroutine, thus generating intermediate results. Therefore, no permanent set of machine instructions is produced. Hopper listed the following steps as occurring during the interpreter process:
1. Transfer arguments to the subroutine or to some standard location
2. Mark position in the main routine
3. Transfer control to the subroutine
4. Carry out the subroutine
5. Transfer control back to the main routine
6. Retrieve results from the subroutine or standard location
Though interpreters were simpler to use than programming in machine code, Hopper believed the approach was a step in the wrong direction. Compiling the A-2 pseudo-code was time consuming in the short term, but the resultant run-program eliminated these six interpretive steps and thus could run more efficiently. In her final comparison of interpreters and compilers, Hopper wrote: “In both cases, the advantage over manual programming is very great, once the basic subroutines have been tested and proved. The saving of time for a compiler is usually greater.”40
DISTRIBUTED INVENTION: EXPANDING THE NETWORK OF INNOVATION
The A-2 compiler, though still cumbersome in many respects, was, in Hopper’s opinion, robust enough to be distributed to UNIVAC I installations for evaluation. But convincing people to use the experimental programming system turned out to be far more difficult than Hopper anticipated, for the advantages of compiled programs were not readily apparent to most: “We found that we had to change from being research and development people and turn ourselves into salesmen and get out and sell the idea of writing programs this way.”41
On 16 July 1953, the Computation Analysis Laboratory turned its attention from inventing to selling and sponsored the first automatic programming workshop in Washington, D.C. With the Census Bureau as a co-sponsor, Hopper invited about 90 programmers and technicians from the various UNIVAC I installations to the one-day event. Hopper’s staff presented lectures on the A-2 compiler and provided demonstrations on the Census Bureau’s UNIVAC machine. Hopper believed the overall reaction to be favorable, and many of the installations agreed to test the compilers during actual day-to-day operations.
Through the fall and winter, installations with experienced UNIVAC programmers fared better than those without, which suggested that the A-2 was not as simple to use as had first been believed. Betty Holberton, now a senior programmer at the Navy’s David Taylor Ship Basin in Annapolis, had little difficulty applying the A-2 to problem solving. But Emil Schell, the head of mathematical computation at the Air Force’s Office of the Air Comptroller, was less successful in applying the new technology. “The writing of the pseudo-code words, the specifications for generating subroutines, and the use of the modifying indicator in ‘own codes’ involve decisions of a sort we are ill-equipped to make,” wrote Schell. In order to help his installation get up to speed, he requested that Hopper send more and better expository materials and operating instructions.42
By December 1953, the Census Bureau, the Office of the Air Comptroller, the Army Map Service, the David Taylor Model Basin, Lawrence Livermore Laboratory, New York University, and the Bureau of Ships were experimenting with the A-2 compiler. The Computation Analysis Laboratory gained valuable feedback from these installations, including the identification of subroutine and pseudo-code errors and suggestions concerning future iterations of the compiler system. Some installations went as far as to rewrite code, which was then evaluated by Hopper and incorporated into later versions of A-2. For example, during the winter of 1954 Nora Moser of the Army Map Service sent Hopper a list of innovations that the Army Map Service had incorporated into the A-2, including more efficient input and output generators, rerun provisions, and an editing subroutine library. Moser had also copied the changes onto magnetic tape and sent them to Betty Holberton at the David Taylor Model Basin for further evaluation.43
Hopper’s constructed network of compiler developers was unique for a variety of reasons. Whereas Howard Aiken had isolated the Harvard Computation Laboratory from other computer projects, Hopper realized that the process of invention could not be confined to the artificial boundaries of her staff or even her company. Information flowed smoothly between Remington Rand and other organizations, with Hopper serving as the conductor of invention rather than its dictator. Though she insisted that copies of all correspondence be passed through her, Hopper did this in order to better orchestrate the efforts of others rather than to control the direction of compiler development.44
Moreover, Hopper’s network of invention attracted the enthusiastic participation of many women in the programming field. Nora Moser (of the Army Map Service), Betty Holberton (at the David Taylor Basin), Margaret Harper (of the Remington Rand/ Naval Aviation Supply Office), and Mildred Koss (of Remington Rand) viewed the compiler as more than just a new programming concept. Indeed, they saw it as the centerpiece of an innovative automated system of programming that they had a hand in creating. Though posterity identifies Hopper as the leader of this programming revolution, one must not forget the many men and women who helped to transform Hopper’s original prototype into a viable commercial automated programming system.
Hopper nurtured her growing distributed network of invention by arranging a second workshop on automatic programming, held on 1 December 1953 at the Pentagon and co-sponsored by the Air Force. Hopper kicked off the workshop with a paper titled “Progress in Automatic Programming.” Once again her staff provided descriptive lectures and demonstrations, but this time multiple UNIVAC installations reported on the benefits and difficulties associated with applying compilers to real-world computational situations.45
The audience of more than 100 also included many people not associated with UNIVAC installations. Hopper recalled that representatives from government agencies and businesses equipped with IBM machinery came to learn more about the new concept in programming. In fact, the December conference was not the first attempt by Hopper and her team to educate the wide
r computing community about the A-2. At a September 1953 meeting of the Association of Computing Machinery at MIT, Hopper organized a panel that served as a “coming out” party for her automatic programming faithful.
The fact that Hopper wholeheartedly welcomed non-UNIVAC personnel to learn about the A-2 compiler sheds some light on her beliefs concerning intellectual property. Hopper did not view software as a commodity to be patented and sold. Rather, she took her cue from the mathematics community. Like most other academics, mathematicians shared information universally, in order to advance knowledge. Though individual efforts were acknowledged by colleagues, advancement in the field was contingent on a communal view of information, community validation, and evolutionary advancement based on previous work. In the same way, software, according to Hopper, was a public good to be shared freely among all users. Complicating software development with secrecy would only inhibit innovation. Learning from the Harvard Computation Laboratory’s tendency to isolate itself from other computer developments, Hopper came to realize that a distributed network of inventors, each with his or her particular technical perspective,46 could sustain a faster rate of innovation in the long term compared to an individual inventor or even an isolated team of inventors. The freeware and open source movements of the present day preserve this doctrine. The roots, however, go back to Hopper and her team of distributed inventors.
After Hopper’s remarks concerning general compiler developments, two of her protégés, Adele Mildred Koss and Harry Kahrimanian, presented compiler-related papers. Koss discussed an “editing generator” that could manipulate raw results into a form suitable for printing. That is, the editor supplied titles, headings, and page numbers, suppressed unnecessary zeros, and inserted decimal points and plus and minus signs. Koss’s editor did this by means of a special type of compiler called a generator. The generator contained what Hopper referred to as “coded coding,” which, on the basis of specifications inserted by the user, expanded into a limited subroutine containing the controls necessary to process the data.47