Metropolitan Honeywell Compiler(ID:5856/met034)"English Language Compiler" for Honeywell by Metropolitan Life Insurance Company. Developed as a platform-independant alternative to COBOL, B-0, FACT. Paired with Metropolitan UNIVAC Compiler Related languages
References: Early programming experience To return to the software story: those of us who did the original programming on Univac I in 1953 and 1954 started out being thoroughly indoctrinated with the virtues of machine coding. In 1953 there wasn't much of anything else anyhow. In 1954 we were very fortunate in getting a "compiler," produced at New York University by Roy Goldfinger. It amounted to what we would nowadays call an assembler, in that it allowed subroutines to be stored on a library tape, to be called in by a programmer at assembly time. We recoded it in our shop to add some features we thought desirable, later recoded it again for Univac II, and it is still one of the basic Metropolitan assembly systems for Univac II programs. It is a sobering reflection on the fantastic progress of computer technology in the last 10 years to remember how avant-garde this assembly system appeared to us in 1954, and what a great help it was in our programming work; then to come back to the present day, when an assembly system is taken for granted, like a self-starter on an automobile. A few years after our 1954 start, the first ideas about using problem-oriented languages for coding were being discussed, advocated, sneered at, and praised. We programmers thought these efforts quite impractical, but our higher management saw them as rays of hope on the horizon. Systems and claims for systems that used actual English language words came into being: B-0 Flowmatic, COBOL, FACT. We tried out the B-0 system on our own machines. The early efforts at implementing these languages on the small-memory machines then available produced results that were such that we had no trouble recognizing their impracticability. But these systems had a point which was inescapable: the country simply did not contain enough clever machine-oriented programmers, or people who could be so trained, to cope with the explosion of computer programming that was occurring. So a few of us stopped scoffing, and considered that we didn't really object to the general language approach of these new systems— it was the implementation we didn't like, i.e. the volume of coding generated, and its efficiency in terms of running time of the generated program. Extract: First compiler First compiler In 1959 therefore we decided to make up our own English Language Compiler for the Univac II, designing the language ourselves by considering real existing programs, and requiring it to handle everything we could think of. Before the language was frozen, it was applied to actual production runs, large and complex, to establish its practicability. We were conscious at the time that some new, as yet unknown, machine would replace Univac II within a few years, and tried to keep the language reasonably machine-independent. This first effort in compilers in our shop was working by the end of 1960, and the coding produced was not bad. A basic decision was made during the implementation phase, which we have held to in our later compiler work, and which I consider important: it was decided that the efficiency of the coding produced was far more important than the efficiency of the compiling process. That is, we did not care whether compiling time was fast or slow, but the object program produced had to run fast, and had to use memory space economically. The coding produced had to compare favourably with direct machine-language coding by a human being, although we realized it could never be quite that good. At that time, and you can still see it today, claims of competing compilers seemed to emphasize compiling time exclusively: "Our compiler produced this program in only three minutes, while the Brand-X compiler took five minutes." The Metropolitan Univac Compiler took about an hour, sometimes longer, to produce a full 2,000 word program. This is one of the reasons why I stressed earlier in my talk the importance of considering the environment in which software is used before evaluating it. Our data processing activity features many recurring jobs, few one-shot jobs. The extra time we take to compile is more than recaptured once a job goes into periodic application. Obviously a service bureau would take the opposite point of view, and correctly. Extract: Compromise compiler for H-800 Temporary compiler for H-800 To return to the English Language Compiler situation: we started immediately to work on an H-800 version, that is, one to produce H-800 coding, but wisely decided to program it for the Univac II. This had several immediate advantages. First, we had a fluency with Univac II language that we knew would take some time to develop with H-800 language, and we knew how to debug Univac programs well, with six years' experience. Second, we could test it out as we went, on our own machines in our own shop, without getting into a queue for time on the few H-800 machines then working, all of which were outside our office. Third, about one-third of the job was already done, since the preliminary syntactical analysis in the working Univac compiler required few modifications to serve the same purpose in a Honeywell compiler. Of course, we knew it could not be a permanent solution, but the fact that we intended to phase out the Univac II machines only very gradually made it a very acceptable solution. I can't resist pointing out that this decision, to implement an H-800 compiler on a Univac II, is one that only a user could have made, and is a good example of the advantages, sometimes unexpected, of a computer user furnishing some part of his software requirements himself. It was a slick way of getting work onto the new machines quickly. It is entirely possible that our inability to do this type of work would have set our whole time-table back a year or more. One of the many good points we considered about the H-800 was its relatively early availability, compared with some other machines we studied—this advantage might have lost its appeal if we had not been confident that our own staff would be adequately supplied with tools to exploit the advantage of an early hardware installation. This hybrid compiler was called the "Compromise Compiler"—a misleading name perhaps, but we did not feel that the name had much importance except to identify it. We have never been very keen on tricky names in the Metropolitan computer division. The wholly H-800 compiler that eventually replaced the Compromise Compiler really has no name at all, except "The Compiler"—The Executive Routine is simply called that, or sometimes "Met-Exec." We marvel at the ingenuity that other people display in coming up with those wonderful acronyms like COBOL, ADMIRAL, FACT, SOAP, and the like. We wonder where they find the time for such research. Many acronyms have such an ultimate flavour about them that they seem to leave little room for improvement. The original UNIVAC, for example, which is now carefully preserved in the Smithsonian Institution in Washington, along with Lindbergh's airplane, had a name that meant "Universal Automatic Computer." Where can one go from there? Nor is this a peculiarly American disease: I had pangs of envy and admiration when I first heard about the great Nebula compiler in Orion; that one deserved a prize. I suppose I can sum up these parenthetical remarks by saying that we don't care what people call it, provided it works. A few minor modifications in the compiler language were made in adapting the compiler to the H-800. These had to do with methods of identifying tapes, and some related to the matter of running under the control of an Executive routine. No changes at all affected the processing language itself, and it was fairly easy to spot and change Univac statements that required changing in order to recompile on the Compromise Compiler for the H-800. Although the New York machines originally had 16,000-word memories, our smaller machines in San Francisco and Ottawa, installed in 1962, had 12,000 and 8,000-word memories, and in order to be able to run each other's programs, we restricted H-800 program size initially to 6,000 words of memory. This restriction had the desirable effect of permitting parallel operation to some extent, at least in New York. Where the Univac Compiler took about one hour to produce programs restricted to the size of the Univac 2000-word memory, the Compromise Compiler took from two to three hours to produce an H-800 6,000-word program— the correlation between time of compiling and memory size of the compiled program was quite close. Later, in 1963, we doubled memory size on the New York machines to 32,000 words each, and the San Francisco and Ottawa machines were increased to 16,000 words each, and at the same time we raised the permissible size of a program to 12,000 words. This of course made compiling time rather enormous on those few programs that went to very large sizes, but it occurred at a time when enough work had been transferred from Univac to Honeywell to make such time available. The "pure" Honeywell compiler (i.e. compiling runs on the H-800 for the H-800) went into operation in September of 1964, and the whole problem of excessive Univac compiling time promptly disappeared. We had scrapped one of our Univac II machines in May of 1964 (we tried to sell it, but no one wanted it even as a gift), in order to provide floor space for an H-1800, and it was a great relief when the new compiler started operating four months later. The risk of not having enough time to compile for new trials being worked on during those four months was not a real one, since we could have bought some time outside—but this was not necessary, as it turned out. During the years that we used the Compromise Compiler, about 500 programs were produced by it, and no other programming system had to be used for regular production type work. Programmer confidence in the system is very high, and has continued high with the introduction of the newer all-Honeywell compiler. One simple indication of this acceptance is the fact that when bugs show in test sessions the normal reaction is to examine the statements for errors first, not the coding produced. Project leaders and managerial personnel above the programmer level are completely sold on the system, and it is generally felt that the progress we have made over the last few years would not have been possible without the compiler. Extract: Final Honeywell compiler Final Honeywell compiler Work started on the "pure" Honeywell compiler about 27 months prior to its completion in September of 1964. There was less urgency, except at the very end, and we wanted to gather up all those tidbits of hindsight that the two earlier compilers gave us, and really do a good job. Rule: if you want a job done well, do it the third time. After only one year of its development, the partially completed compiler started to pay large dividends, since its very complete and fast diagnostic section was working by then. This enabled us to find programmers' errors very rapidly on the H-800, then send to Univac only those programs that were clean—this simple step cut Univac compiler time requirements in half. Language changes for the third compiler were confined to liberalizations of some prior restrictions—there were no changes that required rewriting older programs for the new system. A king-size program that requires 12,000 words of memory can be compiled in less than an hour—the average run is about 30 minutes. We are now compiling about 20-25 programs per month, not counting about twice that number per month of partial runs that reveal programmer logical errors. Some of the features of our latest compiler may be of interest. Half-way through a compilation an English Language analyzer is produced, which lists the original statements' text, and shows all cross-references between statements. This is valuable for making later program changes. Lists are also given of the various files, data nouns, storage areas and tables used in the program, showing the statement numbers of all processing steps that refer to each. If there are any errors in the program this list is also present, and the compiler quits without going further. The Honeywell symbolic coding language, which the compiler produces, contains a provision for inserting "remarks" lines among the coding. The compiler uses this facility in two ways: first, each small section of coding, which corresponds to a clause of a statement, is preceded by remarks that give the statement and clause number, as well as the English text of the clause. Second, the entire original text of the program is converted to remarks lines that appear at the end of the program listings. Having all this information in one package helps program maintenance considerably. Extract: Verbosity defended Verbosity defended A frequently heard criticism of English Language programming is that it is too verbose in stating a problem. Some suggest allowing one to write RD instead of READ, or A instead of ADD. A similar complaint has to do with our insistence on programmers attaching meaningful names to data fields—instead of calling them INSURANCE, COMMISSION, PREMIUM, the suggestion is to allow something short, like Al, A2, A3, on the grounds that the programmer will know what he is doing, and why write all those extra letters? There are several replies to this line of thinking: (1) The redundancy in "ADD," as compared with "A," is a valuable error-detection device, to guard against some random key-punch error changing the meaning of a whole processing step, without immediate detection. If A stands for ADD, and S for SUBTRACT, how easy is it for a careless operator to punch one instead of the other? But mere carelessness will never give SUBTRACT instead of ADD. Very well then, but why not allow SBTRCT instead of SUBTRACT? The answer is that anyone can spell SUBTRACT, but why need one take the time to look up SBTRCT in a list of authorized abbreviations? (2) An English Language Compiler is not merely an instrument for converting a problem-oriented language into a machine-oriented language. It is also a communication and documentation device, which allows close supervision of programmers during the development phase of a project, as well as providing for easy transfer of programs from one group of programmers to another. Where a program has been doing steady production work for a year and now needs revision, use of this type of compiler facilitates the job of refamiliariza-tion. All of these advantages tend to drop in effectiveness if there are special symbolics used whose meaning is not readily obvious. (3) In any event, no one programs at dictation speed, or even writing speed. The amount of time it takes to decide what to write is far greater than the amount of time it takes to write it. Extract: ARGUS and Mercury I will return to the compiler story later, but it might be well to mention here three other aspects of H-800 software which had to be evaluated. One was the ARGUS assembly system, for converting mnemonic coding into machine coding, and bringing library routines into a completely assembled program. Another software question, though not a program, was the Honeywell convention system in regard to data tape layout, handling of signs, rules regarding the handling of parallel-running programs, etc. The third major question was the Executive Routine. The ARGUS assembly system appeared to be in good working order, and although we did not want to use all of its various features, the ones we needed seemed satisfactory, so we decided to leave well enough alone in this area, for a few years' time at least. Much later, in December 1963, we started work on a replacement for it, and this is now coming into use in the Company. The replacement, which we call "Mercury", is much faster, and has tighter controls. in The Computer Journal 8(4) 1965 view details |