GPX(ID:78/gpx001)General Programming Extendedfor General Programming, eXtended Language system for the UNIVAC II, implementing structure programming and libraries. Places People: Hardware: Related languages
References: in [ACM] CACM 1(06) (June 1958) view details in [ACM] CACM 1(06) (June 1958) view details In these remarks, I do not propose to describe an automatic coding system. My aim is, rather, to present an approach to automatic coding or, if you prefer, to present a motivation which has guided us in the development of the three actual systems for Remington Rand computers. The earliest of these three systems, developed for the UNIVAC I, has been known by the name Generalized Programming. (This system was recently renamed FLEXIMATIC by the Remington Rand Sales Office.) In operation for approximately two years, GP is currently employed at a considerable number of commercial installations. The second system, Generalized Programming Extended (GPX), is a new version of FLEXIMATIC for the UNIVAC II; it has considerably increased powers in comparison with its ancestor. Currently, we are building the third system for the LARC computer. During years of development, the aims we wish to achieve have only gradually become clarified. Therefore, the system now in preparation for the LARC represents the fullest realization so far of these aims. The ensuing discussion will use the term "the system" to refer to an embodiment of the aims to be described. In point of broad classification, the automatic programming system developed by the UNIVAC Applications Research Center is a compiler. This means that it shares two important characteristics with other systems similarly classified. First, complete solution of a problem with the aid of the system involves two computer steps: (1) translation of an encoding of the problem (in a special form associated with the system) into a computer-coded routine, and (2) actual problem computation. The second characteristic common to all compilers is that during the translating process, reference is made to a collection of packages of information, usually called library subroutines, which contribute in some way to the final result. The system differs from other compilers, however, in that it aims to provide the programmer with a set of services equally applicable to the solution of any problem--services, in other words, which are claimed to be altogether "general purpose." Therefore, the system contains no special design features which make it better adapted to one area of computation than to another. This aim, as stated, raises a peculiar question: A general purpose computer is, itself, supposed to provide a code which is equally well adapted to all areas of computation. To claim that it is profitable to build a programming system which contributes equally to all problems is, of course, to claim that some facilities which have "general purpose" standing are not realized in the hardware of a general purpose computer. We believe that such unrealized facilities exist and that they lay the basis for a powerful programming system. The facilities in question are an addition to the computer and, in no sense, a subtraction. Hence, a program in the system code may possibly be a one-to-one image of a computer-coded program. The general purpose facilities I have in mind fall into two broad categories, the first of which--naming aids used in writing computer instructions--has already been widely recognized in the computer field. Naming aids include symbolic addressing, convenient abbreviations to represent computer instructions, special conveniences in the naming of constants, etc. Such naming aids, while interesting in their own right, have already been exploited to a greater or lesser extent in many existing assembly routines. It is apparent that these conveniences are equally applicable to all programs in which computer instructions must be used. The second facility for which I claim general purpose standing is the ability to use mnemonic and abbreviated notations to represent computations of some given type. In part, this means the ability to use, in addition to the elementary computer instructions, special purpose instructions which are helpful in a given type of computation. By a few examples, I hope to show you the range of special notations I have in mind. Suppose, for instance, that I have frequent occasion for evaluating sines of angles and that the computer does not contain a special instruction for sine evaluation. In addition to my usual command vocabulary, which the computer interprets directly, it would be a considerable convenience to write a special command which represents sine computation. Perhaps in different problems I require sines with different degrees of accuracy. In that case, my notation for sine computation may also mention a desired accuracy. In any event, the special notations which represent the sine computation may be viewed as a special encoding of the sine function which must be translated into computer code before the program may function. Such translation is normally accomplished by reference to a so-called library subroutine, introduced by a compiler at the point at which the special notations were originally written. Sine computation, with or without parameters, exemplifies a large family of cases in which it seems convenient to introduce special notations to represent functions which the computer cannot execute directly. Another example of special notations not usually considered to have much in common with a sine routine call is the use of algebraic notation to represent the evaluation of algebraic expressions. A little reflection shows, however, that both of these cases have important properties in common. In fact, they are both special notations used as part of coding to represent certain types of computations. In the case of sine with specifiable accuracy, we "code" a sine routine by mentioning the word sine and a chosen accuracy number. In the case of algebra, we "code" an algebraic evaluation by writing the appropriate expression with algebraic notation. In both cases, these special notations must combine with information stored elsewhere before they become coding which is intelligible to the computer. In the case of special notations for sine, the "other information" is usually thought of as a library subroutine. A compiler then serves to interpret the special notations by finding the library subroutine and, perhaps, by inserting a specified accuracy value into the library coding. In the case of algebra, it is common to think of the "other information" as an algebraic translator which operates as an entity by itself. It is my contention that either special notations for algebra or special notations for sine may both be handled by a general purpose compiler which has broad ability to combine library information with special notations employed in the original coding. Still other types of special notations which may offer great conveniences in the writing of code for special problems may also be handled by a general purpose compiler. For example, suppose that I have a file of information on which several different types of processings are to be accomplished. This file contains complex items, each of which is subdivided into many fields containing quantities that may be mnemonically named. It would now be a great convenience if, in my coding, I could refer to the quantities contained in this item by mnemonic names which have been agreed upon as appropriate to that file of information. A general purpose compiler can assist the translation of such special mnemonics with appropriate packages of library information. A package of library information is combined with special notations employed in the original coding to produce coding in another form. The combining agent is a general purpose compiler. The library packages discussed here have wide use and diversity of structure; so-called library subroutines, on the other hand, are only one example of the library packages which a general purpose compiler can use. In the development of most compiling systems, the designers begin with a special range of problems for which they intend their system to be useful. They invent special notations which they consider naturally adapted to the area of problems in question, and then they construct a translating mechanism with just enough generality to cope with these notations. While a given set of special notations for a given area of problems may, indeed, be very useful and important, the ability to add arbitrary, new notations is even more important than any given set of special notations. The truth of this may be readily appreciated if we realize that no one set of special notations can be optimally adapted to all ranges of problems. No single computer would be optimally adapted to all types of computation. Furthermore, we cannot even hope, once and for all, to subdivide the entire universe of problems into fixed areas, each with a well-adapted notation. For example, if I have devised one notation satisfactory for business problems and another notation satisfactory for algebra, I am still unable to write convenient coding for problems which lie squarely between these two areas - namely, those problems which involve a lot of data handling and algebraic computation. Even if problems which cross the boundary lines never arose, the inability to add new notations would, nevertheless, be hampering. Suppose, for example, that a notation has been developed to handle all algebraic problems with equal facility. If, now, in a certain set of problems, I use frequently either a particular algebraic function or a particular succession of steps, I will find that the general algebraic language at my command causes me to write much more than the particular set of problems requires. In short, as soon as the range narrows from all of algebra to a special sub-domain of algebra, the general algebraic notation ceases to be well-adapted. In summary, it is possible to construct a general purpose compiler which (a) provides special conveniences in the writing of computer code (naming aids) and (b) provides the ability to add new notations to my repertoire for instruction writing whenever such notations seem profitable for particular ranges of problems. Of course, profit is a relative thing. In exchange for the advantages bought by having certain new notations available, I must labor to add to the library packages which make translation of these notations possible. Consequently, this central feature of the general purpose compiler is truly meaningful only if the labor required to obtain the use of new notations is comparatively small. The theoretical foundations for such compiling systems are now being developed at Remington Rand. Early examples, such as GP for UNIVAC I, demonstrate the practical utility of a system designed from this point of view. in [ACM] CACM 1(05) (May 1958) view details in [ACM] CACM 1(05) (May 1958) view details Bob Bemer states that this table (which appeared sporadically in CACM) was partly used as a space filler. The last version was enshrined in Sammet (1969) and the attribution there is normally misquoted. in [ACM] CACM 2(05) May 1959 view details in [ACM] CACM 6(03) (Mar 1963) view details Another and quite independent group at Univac concerned itself with an area that would now be called computer-oriented compilers. Anatol Holt and William Turanski developed a compiler and a concept that they called GP (Generalized Programming). Their system assumed the existence of a very general subroutine library. All programs would be written as if they were to be library programs, and the library and system would grow together, A program was assembled at compile time by (he selection and modification of particular library programs and parts of library programs. The program as written by the programmer would provide parameters and specifications according to which the very general library programs would be made specific to a particular problem. Subroutines in the library were organized in hierarchies, in which subroutines at one level could call on others at the next level. Specifications and parameters could be passed from one level to the next. The system was extended and elaborated in the GPX system that they developed for Univac II. They were one of the early groups to give serious attention to some difficult problems relative to the structure of programs, in particular the problem of segmenting of programs, and the related problem of storage allocation. Perhaps the most important contribution of this group was the emphasis that they placed on the programming system rather than on the programming language. In their terms, the machine that the programmer uses is not the hardware machine, but rather an extended machine consisting of the hardware enhanced by a programming system that performs all kinds of service and library maintenance functions in addition to the translation and running of programs. in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details in [ACM] CACM 15(07) (July 1972) view details |