TALK(ID:3246/tal007)EE Commercial AutocodeCommercial Autocode for English Electric Leo KDF6 based on Dijkstra's Algol 60, but adding alpha-based stack operations for business Related languages
References: Introduction It is desirable to begin by defining what we mean by a compiler. In the broadest terms this might be described as a Programming System, running on some computer, which enables other programs to be written in some artificial source language. This result is obtained by the simulation of the artificial machine represented by the source language, and the conversion of such programs into a form in which they can be executed on one or more existing computers. This definition, however inadequate, at least avoids any artificial distinction between 'Interpreters' and 'Compilers' or 'Translators'. For although these terms are still in widespread use it now appears that the distinction between them is only valid for particular facets of any modern programming language, and even then only as a rather inadequate indication of the moment in time that certain criteria are evaluated. On the more positive side the definition does bring out a number of points which are sometimes forgotten. 1 . The Compiler as a Program A compiler is a program of a rather specialized nature. As such it takes a considerable time and effort to write and, more particularly, to get debugged. In addition it often takes a surprising amount of time to run. Nevertheless compilers are concerned with the generalized aspects of programming and have in consequence been the source of several important techniques. These could be applied to a wider field if a sufficient number of programmers would take an interest in such developments. 2. The Three Computers There are three possible computers involved-the one on which the compiler will run, the artificial computer, and the one which will execute the program (although the first and last are not necessarily distinct). In general the more that the facilities in the computers involved diverge the harder is the task of the compiler. On the other hand the use of a large computer to compile programs for smaller computers can avoid storage problems during compilation, and any consequent restrictions in the language, and make the process more flexible and efficient. This can be readily appreciated from the fact that some COBOL compilers running on small computers take more than forty passes! But the full benefit of large computers used at a distance for this purpose is dependent on cheap and reliable data links, since at the moment they introduce delays in compilation and the reporting of errors. 3. Presentation to the User Any user of the system must, to be effective, learn how to write programs in the artificial source language which will fit the capabilities of both the artificial and the actual object machine. This requirement has become obscured by the current myths of the so-called 'Natural' or 'English' langu. ages, and the widespread claims that 'anyone can now write programs' are highly misleading. Indeed existing source languages are rather diacult to learn and show no particular indication that they are well adapted toward the task for which they are intended. A more serious drawback of the 'Natural' language approach is that it hinders or prevents the new facilities being presented in terms of a machine. This is unfortunate because to do so would probably give a better mental image of the realities involved and a better understanding of the rules and restrictions of the language, which tend to be confusing until it is appreciated that they are compiler-, or computer-, oriented. Extract: The Main Requirements of a Commercial Compiler The Main Requirements of a Commercial Compiler A major problem in commercial compilers is the diversity of the tasks which they are required to achieve, some of which often appear to have been specified without regard to the complexity they introduce into the compiler compared to the benefit they confer on users. This ambitiousness may be contrasted with that of the authors of ALGOL (Backus et al., 1960) who concentrated on the matters which were considered important and capable of standardization (e.g. general procedures), and largely ignored those considered of lesser importance (e.g. input/output). There is no doubt that this concentration is the chief reason why ALGOL compilers normally work on or about the date intended whilst commercial compilers normally do not. The main tasks which are commonly required are discussed here. 1. Training and Protecting the User The System must enable intending users who have no previous experience of computers to obtain that experience. This means that the language must include both a 'child's guide to programming' and the facilities which the user will require when he actually comes to writing real and complex programs. In addition the compiler is expected to protect the user, as much as possible, from the results of his own folly. This implies extensive checking of both the source and object program and the production of suitable error reports. But the main difficulty is to provide error protection which is not unduly inefficient in terms of time or restrictive on the capabilities of the user. 2. Data Declarations The declaration of the properties of the users' data should be separable from the procedures which constitute a particular program, because the data may have an independent existence that is quite distinct from the action of any one program. Thus for example a Customer Accounts File of a distributing company may be originally set up by one program and regularly updated by a number of others. In terms of the 'global' and 'local' concepts of ALGOL this introduces a 'universal' declaration which is valid for all, or a number, of programs. This requirement means that the compiler should keep a master file of declarations which is accessible to all programs, and at the same time provides the means of extending, amending and reporting on the contents of this file. 3. InputlOutput Data The input and output data must have a wide range of formats and representations because it is normally intended to allow users to continue with the same media, and the same codes and conventions, which they employ at present. And there is of course no assurance that these conventions were designed, or are particularly suitable, for a computer! This is the kind of requirement which is very hard on the compiler writer. If the specification of format and any other information is to be made in the data description it must be done in a way that is understandable and not too complicated for the users, which means the compiler may not find it simple to pick up the relevant parameters. The actual process of implementation is a choice of one of the following. (a) A very generalized routine is built to cover all possibilities. This is safe but inefficient in the average case. (b) A fairly general routine is built to cover the anticipated range. This is less safe but only slightly more efficient. (c) Individual routines are constructed for each particular variation. This is very efficient but also very expensive in terms of compiler effort. (d) A combination is provided of both (a) and (c) which is economical only if a correct guess has been made of the most commonly occurring cases. But this is of course the type of quandary which arises in several different areas of a compiler. 4. Properties and Manipulation of Data It must be possible to form data structures during the running of the object program and to be able to manipulate data in a reasonably general way. The latter has been deliberately left indefinite because there is considerable disparity between the different commercial languages as to both the properties and the manipulation of data. The points of distinction are: (a) Whether the most common unit of data (normally referred to as a Field) should be allowed to vary dynamically in length. The argument in favour of this property centres on such items as postal addresses-these usually vary between twenty to 100 or more characters with an average of forty or less. This property has a very marked effect on the compiler. Not only must the address determination of such fields be handled in a particular way but other fields may have to be moved round dynamically to accommodate their changes in length. (b) Whether two or more Lists of fields (i.e. vectors) should be allowed in the unit of data handled sequentially on input and output (normally referred to as a Record). Some types of Record kept by conventional methods are claimed to have this property but it is very difficult for a compiler to handle more than one list economically. The problem is simply one of addressing when the lists grow unevenly. (c) Whether characters within fields should be individually addressable. This is the kind of facility which is very important when master files are being loaded on to magnetic tape for the first time. Such loading often constitutes the largest single task of an installation and may be very complex because of the variety of media in which parts of these files were previously held. The addressing of characters even on fixed word machines turns out to be quite simple using a variation of the normal representation of subscripts. There is a greater emphasis on the efficiency of object programs in Commercial as opposed to Scientific Languages due to the higher frequency of use expected of such programs. Unfortunately this emphasis usually takes the form of rather superficial comparisons in terms of time, whereas on most computers actually available in Europe space is the dominant factor. The distinction between the two is however as valid for a compiled program as any other, the production of open subroutines will take least time and most space whilst closed subroutines, particularly if the calls and parameters are evaluated at object time, will take most time and least space. 6. Operating Characteristics Little attention is normally given to the operating characteristics of either the Compiler or the Object Program until some user is actually running both. Yet both are important in practice. In regard to the former this involves inter alia the details of loading the compiler and source programs, the options available in the media of the Object Program and the production of reports thereon, and the actions to be taken on the detection of errors. They are all quite trivial tasks for the compiler and usually depend on the time available to add the necessary frills to make the compiler more convenient to the user. The operating characteristics of the Object Program are much more serious and largely dominated by the question of debugging and the action on errors detected through checks inserted by the compiler. There is no doubt that the proper solution to both lies in making all communication between the user and the machine in terms of the source language alone. At the same time the difficulty is obvious because there is no other reason why such terms should be present in the Object Program. In addition the dynamic tracing of the execution of the program in source language is hindered both by any optimization phase included in the compiler, and by the practice of compiling into some kind of Assembly Code. No existing Commercial Compiler has succeeded in solving this problem. Instead it is customary to print out a full report of the Object Program which is related to the source language statements (e.g. by printing them side by side). Error messages will then refer to that report and special facilities may be provided to enable test data to be run on the program with similar messages as to the results obtained. It will be apparent that this is not very difficult for the compiler, since it is normally possible to discover what routine gave rise to an error jump, but more knowledge is required by the user in terms of the real machine than is otherwise necessary. The other items which can be considered as part of the Operating Characteristics are greatly assisted by the hardware facilities available and include: (a) checks that the correct peripherals have been assigned, and the correct media loaded, for the relevant program; (b) changes in the assignments of input/output channels due to machine faults, and options in peripherals for the same reason; (c) returns to previous dump points particularly in regard to the positioning of input/output media. in Wegner, Peter (ed.) "An Introduction to Systems Programming" proceedings of a Symposium held at the LSE 1962 (APIC Series No 2) view details in Wegner, Peter (ed.) "An Introduction to Systems Programming" proceedings of a Symposium held at the LSE 1962 (APIC Series No 2) view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (4) 1964 Pergamon Press, Oxford view details in ACM Computing Reviews 6(04) July-August 1965 view details in Computers & Automation 21(6B), 30 Aug 1972 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in Computers & Automation 21(6B), 30 Aug 1972 view details |