The Share 709 System: Machine Implementation of Symbolic Programming

Abstract
As emphasized in the preceding paper, a fundamental requirement for effective utilization of high speed computing devices such as the 709 is a man-machine communication link that is at once rapid and unambiguous. Use of symbolic languages with conventional conversion techniques has resulted in reasonable initial specification of computational problems, but excess input handling has made such procedures uneconomical for the tedious corrections incumbent on the best of programmers. Also, checkout is frequently awkward, due to the inability of current systems to permit dynamic requests and responses in a language familiar to the writer. It is an objective of the system design to provide a mechanism for preservation of symbolic language communication between coder and calculator during the entire process of preparing, verifying and executing a program. Decisive in the accomplishment of this aim is recognition of a distinction between the information content of a language and the methods of encoding that language for presentation. Standard routines for translation of symbolic to absolute machine language uniformly result in information loss. This is not the case in the 709 system; only the syntax, not the semantics, are changed. Apart from mnemonic aids, the principal feature of symbolic coding is that referents and their relata maintain the same association when intervening elements are altered in number. A price is paid for this freedom as symbolic languages are uninterpretable by machine circuits without aid. A special program is required—an assembler. The principal disagreeable characteristic of an assembly program is the amount of time it occupies in execution. By attempting to minimize the frequency of reassembly, the programmer is forced to employ two languages in parallel. Logic shows that the only escape from this dilemma is to place some burden of the assembly on that program which loads codes into the machine storage for immediate execution. At once a question arises concerning the propriety of performing even a partial assembly at each machine pass. It is apparent to anyone familiar with historical assembly programs that the major time involved comes not from the internal processing but from the considerable read-in time associated with the usual methods of representing symbolic information. As this information is originally written by a human coder and then reproduced into, say, punched cards, again by a human operator, it is evidently impractical to start the process with binary encoding or some other form of compact expression. It is, however, possible to reduce this original writing to some new form of condensed encoding by computer processing and to use this form exclusively in subsequent operations. With care this can be done and not destroy the desirable features of the original representation. The basic concept in this system is a second encoding schema for the information concerning a program originally described in the symbolic language. This encoding, called the “SQUOZE encoding,” is at variance with the programmers' encoding in several respects. First, it is fundamentally binary, employing only two basic marks, while the programmer enjoys the use of 50. Secondly, the organization of information is quite different in the SQUOZE encoding. All information concerning a particular instruction occurs together in the original expression. This is not the pattern in the SQUOZE encoding. For example, the location symbols associated with the various instructions and storage cells are collected in a single, separate list. This proves to be most desirable for computational purposes when consideration is given to the special role played by such symbols. Finally, and with perhaps the most significance to the casual observer, the SQUOZE encoding is far more conservative of bits than the pseudo-English used by the programmer. It is from this phenomenon that the scheme derives its name, “SQUOZE” being a bastard past participle of the verb “to squeeze.” This condensation, which is on the order of ten to one, does not alter the functions of the system, but it does provide a considerable decrease in the time involved in processing program input, a major criterion for acceptability to those concerned with machine rentals. The critical difference from other systems inherent in the SQUOZE encoding is the retention and reorganization of information concerning symbols. It is this element that makes possible the more desirable modification and checkout procedures. Condensation does nothing more than make this sophistication cheaper and therefore more palatable. While clearly less redundant than the usual mode of expression, the SQUOZE encoding is not based on a minimum redundancy code. There are two reasons for this. In the first place, the construction of a true minimum redundancy code is not possible without precise knowledge of the probabilities of the various elements involved. Such data would be hard to come by for a programming language on an untried machine. Also, in the general case, a minimum redundancy code requires bit by bit examination for decoding. In the 709 this would require more internal processing time than would be saved on input read-in. It is evident that a compromise is necessary. A single example will suffice to illustrate the pattern of exchange between decoding time and input time. When the various macro instructions are adjoined to the actual 709 instructions, the number of operation codes which the loading program must recognize approaches 250. Allowing for later expansion, a principle that has been followed throughout the system, nine bits would be required for an elementary table description of the operation code list. Had this mechanism been adopted, only a single table lookup function would be required in the decoding program for the determination of the operation codes. If the exact frequency ranking of the operation...