COMPL(ID:248/com030)AG Fraser (Cambridge University Mathematical Laboratory) and JD Smart (ICT) Part of the NEBULA compiler for the ICT Orion computer Related languages
References: Extract: Introduction Introduction The NEBULA compiler for the I.C.T. Orion computer (Braunholtz, 1961) is probably one of the largest software projects yet undertaken outside the United States. The compiler itself contains about 250,000 words of program, and was written by a group which, at the later - - stages, contained some 28 programmers. At an early stage in the design of the compiler it was realized that it would be necessary to employ a compiler if the task were to be completed successfully. In practice the early decision to use the computer as a tool in the preparation of the NEBULA compiler has been the one main feature without which the compiler would certainly have failed. The early problems of technical design were later enhanced by the needs of a group of programmers working on a common program. This latter situation led to the need for extensive standardization in all aspects of program writing, development and maintenance. Every effort was necessary to ensure compatibility between the various components of the one program, and to this had to be added the controlled flexibility needed to develop and assemble the component parts of the system. These considerations gave rise to the design of an operating system which contained, and was integral with, the compiler group's own compiler. The source language used by the NEBULA team is called COMPL and it is this specially designed language and associated operating system which is described here. The COMPL system was designed so that it could be used in the final NEBULA compiler itself. The total integration between the two systems has led to a number of operating inefficiencies, but it has significantly assisted both the development and maintenance of the NEBULA compiler. The design of the COMPL language itself reflects the needs of the NEBULA compiler, and for this reason it must be regarded as a special-purpose tool. In spite of this the language, and indeed the entire system, possess properties which could make it interesting to other groups. No creation, when it eventually emerges, will satisfy its creator, and the tortuous history of development which the COMPL system has undergone during the past four years has left it in a form that leaves much to be desired. The reader must therefore regard it as a wellworn tool which was designed to do a specific job of work. Extract: The COMPL system The COMPL system The COMPL system and its compiler are integral parts of a whole, and consequently the language which is used for program preparation merges with the language of directives that control the system. No clear boundary can, therefore, be drawn between the two components. For the purposes of this article the individual procedure statements in a COMPL procedure (or subroutine) will be described under the heading of the COMPL programming language, and all else will be given under the heading of the COMPL system. The system itself is built around its storage organization and it is the latter which is the subject of a major part of the hidden complexity in the systems programs. The principal storage space "known to the user" is a large single-level store of about 256,000 words of 48 bits each. This store is commonly referred to as the "data store." The entire configuration comprising system program and store is best thought of as having a continuous existence. When the system is not actually running on the computer it is held on magnetic tape in the form which it last reached. The process of unloading the system program and data onto magnetic tape is known as dumping and the process of re-establishing the system on the computer is known as restoring. The system can be dumped under operator control at any time. Overall control of the system is achieved by means of a series of directives which are read into the machine from paper tape. The system reads one directive and then carries out the action requested before reading the next directive. One such directive is: PERFORM Test Program; BEGIN 2. This directive instructs the system to find the procedure called Test Program and enter it at entry point 2. There is no STOP instruction in the system but all procedures terminate with the EXIT statement which causes control to return to the higher level. In the case of the above example control returns to the operating system when EXIT is obeyed in the test procedure. The system will then proceed to read and obey the next directive from paper tape. In exceptional circumstances the operator may interrupt the operation of the system by typing a message on the console Flexowriter. This message causes the system to halt the current job, whatever it might be, and to read and obey one directive typed on the console Flexowriter. Having performed the requested action the system continues with the job previously interrupted. The directives that may be given to the system are many and varied but one whose effect has already been described is DUMP. The other directives that are available are listed in Section 6. One important directive which should be mentioned here, however, is the COMPL procedure. The system treats an entire procedure as if it were one directive, and the effect of carrying out this "pseudo-directive" is to compile the procedure and to store it within the system. Having this way "defined a new procedure the user is free to call upon it in any way he wishes. When a procedure is compiled the object code subroutine is left in the data store from where it can be obeyed if necessary. However, this is not usually its final resting place since there is a second storage area reserved and designed specifically for program. This second store is the CHAPTER store. In this second store COMPL object program is stored in 512-word chapters, and it is from the chapter store that a procedure is more frequently obeyed. The process of clearing out procedures from the data store and putting them into chapters is initiated by the directive UPDATE. This is effectively a "spring cleaning" operation which is usually done at regular intervals. Much effort has been put into the design of the system in an attempt to make it do that which is expected of it even in extreme circumstances. One example of this is the fact that a procedure can be executed whether or not an update has been done since it was compiled, in spite of the fact that the two modes of execution are vastly different from an internal viewpoint. The extra effort required to implement this policy of rigid adherence to a uniform design has been proved repeatedly to be sound and, indeed, many cases of common failure can be traced to points where this policy has not been properly carried out. There is a group of directives which are available to the COMPL programmer which enable him to use and test the compiled procedure. PERFORM is a directive that has already been mentioned, and the other directives are directly linked to this. The directive NEST allows the user to set up the 7 nest words (working-space registers described in Section 3) and this setting will apply when the next PERFORM is obeyed. MONITOR is a directive which allows the user to make use of the trace and check-point monitoring facilities that have been built into the system. There are two trace facilities available. (a) The system will print one line on the monitoring peripheral whenever a PERFORM or EXIT is obeyed. (b) The system will produce a train of symbols on the monitoring peripheral which describe the path taken by the object program. Since the user does not usually know the details of the object code this trace is in terms of the source language branching in the original COMPL version. A single letter (N for NO or Y for YES) is printed each time that a COMPL source language condition is evaluated. G is printed if a GO TO statement is obeyed, and the program address of a labelled sentence is printed whenever such a sentence is obeyed. The check-point monitoring facility relies upon check points written by the programmer in his original COMPL version of the program. This, in fact, has proved to be the weakness of the system, and it would have been much more valuable had it been possible to insert check points after the procedure had been compiled. Nevertheless the facility does provide a useful range of printing styles that can be output on the monitoring peripheral. The adequacy of this facility is demonstrated by the way that check-point monitoring has been used regularly in place of the other methods of output for test results. The design of this facility was assisted materially by the discipline which was imposed on programmers in the use of the store, most data being held in a standard and recognizable format. The MONITOR directive itself sets up the styles of monitoring which apply when the next PERFORM is obeyed. In addition to the style of printing the user can monitor on selected procedures and suppress any monitoring action on the others. The remaining directives fall into four major groups. (a) Directives for the administration of the compiled procedures (e.g. CHAPTER which allocates a specified procedure to a specified chapter in the chapter store). (b) Special facilities developed directly in association with the NEBULA compiler. These are aids to the administration and development of the NEBULA compiler while being assembled. (c) Directives which operate on and in terms of the COMPL object program and data store (e.g. LIST allows the user to read a list structure into the data store). (d) Directives for "class definition." (See Section 5 for a description of this specialized part of the system.) in The Computer Journal 9(2) August 1966 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 |