PL/I Checkout Compiler(ID:5998/pli004)Interactive PL/I compiler Related languages
References: The PL/1 Checkout Compiler, released by IBM in November 1971 and developed at the Hursley Laboratories near Winchester, is intended to plug this gap. Working under the Time Sharing Option (TSO) and OS/360, it 1. Provides comprehensive facilities for dynamically debugging and correcting programs. 2. Implements the full PL/1 language. 3. Is designed especially for ease of use at a terminal. External link: Online copy Extract: Design considerations Design considerations Development of the compiler was directed towards satisfying the processing requirements of a broad base of users, while giving them an implementation which was practical and convenient to use. Terminal-based installations are still in the minority, so the compiler is designed to be used as a background processor, as well as in the foreground in interactive and remote-entry situations. A given program may be run on one day in the background, and on another from a terminal: so it is important that the compiler"s capability in background use is a true subset of what it can do conversationally. The Checkout Compiler is intended primarily as a debugging tool, and besides detecting more classes of error than do previous implementations, it attempts to describe the problem to the user in terms of the names, values and relationships of the elements of his program. Debugging aids in PL/I, and special subcommands, can furnish source-level details of the state of the program at any time. This is difficult to accomplish flexibly with a compiler producing machine code, and so the execution stage of this compiler is an interpreter. This is a relatively slow process, but the compiler is intended as one of a "pair" with the PL/I Optimising Compiler (IBM, 1971b), which produces efficient machine code for those finally-debugged programs which need it. This is similar to the technique adopted for the implementation of ALGOL 60 on the KDF9 (Duncan, 1962). The two compilers were designed and built by two groups working closely together at Hursley: the same level of language is supported for each. Conversely, translation of a PL/I program into interpretable text is fast, so that less machine time is lost in wasted translations in the early stages of debugging. A further requirement was that the processing-time attributable to the system scheduler ("job-step overhead") should be reduced to the minimum in order to increase throughput in the system as a whole. This is achieved in two ways. Firstly, translating and executing a program which does not invoke any other can be performed in a single step: there is no intermediate linkediting process. Secondly, any number of programs and their data can be concatenated and run in a single step, using "*PROCESS;" and ""DATA;" separator cards. Fig. 1 illustrates the principle. Translation or execution errors in any constituent program should not affect processing of the rest of the batch. This technique can be used at the terminal as well as in the background: a typical use might be to run several hundred student jobs in one controlled batch in a university computer-science department. The time taken to execute subcommands to perform a "deskcalculator" computation or to respond to an asynchronous (ATTENTION) interrupt is clearly of importance. The response time, though of course dependent on the system load, is intended to be short enough for the user to maintain his train of thought: an average execution rate of 1,200 PL/I statements per second on a System/360 model 65 is reached. The Droblem of what facilities to provide in a conversational system is notoriously one of personal choice. Several useful features evolved to fill gaps found when trying to debug programs written to test the compiler, but the basic subcommands and "character" came from studying other systems such as Conversational Programming System (IBM, 1971c), through language studies at Hursley and by maintaining close contact with other development and marketing groups. The interpretive techniques were proved by a preliminary project undertaken by an Advanced Development group, and re dictions on interactive ~erformance were obtained from a simulation of the system written early in the development of the compiler. The facilities offered include most of those suggested by Barron (1971). Extract: Language facilities Language facilities This is not the place to set out a full map of the highways and byways of the PL/I language. The 'F' compiler (also a Hursley development), released in 1966, implemented a wide range of data types and automatic conversions between them, storage classes, 110 formatting facilities, interrupt handling, etc., providing a programming capability intended for both scientific and commercial environments. Since then, the language has continued to develop, and the Checkout compiler embodies a full im~lementationo f the latest level of PLII. As its' name implies, the compiler is intended primarily as a debugging tool, and besides detecting many types of error itself, it gives a user a powerful set of new PL/I checking aids. CHECK and FLOW The CHECK prefix and ON CHECK condition are familiar to PL/I 'F' programmers. They provide a means of printing out or otherwise examining the value of a variable at the time it is changed. The Checkout compiler extends this function in two ways. Firstly, the CHECK and NOCHECK statements are introduced. These effectively enable and disable the CHECK condition dynamically, and give the terminal user the facility to monitor unexpectedly aberrant variables. Secondly, BASED, DEFINED and parameter variables can be CHECKED, so filling a hole in previous implementations. One essential requirement for a conversational debugging environment is a way of watching, as it happens, where control is going. The FLOW and NOFLOW statements cause a flowtrace to be started and stopped. Each non-sequential change of control is printed on the terminal, as is the flow through an IF/THEN/ELSE sequence. Even if the flow-trace is not switched on, the last n changes of control (where n is specified by the user via a compiler option) can be printed out at any time by a PUT FLOW statement. The PUT ALL statement In extremis, the ALL option of the PUT statement can supply a comprehensive description of the state of the program. Its output can be selectively reduced by a further sub-option, choosing from : 1 . The values of all variables known at this point (uninitialised variables are flagged). 2. The value of each generation of a CONTROLLED variable. 3. The value of the condition pseudo-variables (e.g. ONCODE, ONSOURCE). 4. The status (enabled or disabled) of each condition. 5. Attributes and buffer-contents of all files currently open. 6. A flow trace (see PUT FLOW above). 7. A list of the PL/I blocks in the calling chain. ON ATTENTION A new condition, ATTENTION, enables a program to handle asynchronous terminal interrupts itself. If an ON-unit for the condition is not employed, such an interrupt will give control to the terminal. Some new classes of errors detected The interpretive nature of the compiler enables it to catch many of the more subtle errors not detected by other processors. Some of the most important are: 1. An attempt to use the value of an uninitialised variable. 2. Referencing BASED or CONTROLLED storage which has previously been FREEd. 3. Erroneously setting a POINTER or OFFSET variable to point at gibberish or at an item whose attributes do not match those of the BASED variablt being referenced. 4. Trying to FREE storage which does not belong to a generation of BASED or CONTROLLED storage. in The Computer Journal 15(2) 1972 view details in The Computer Journal 15(2) 1972 view details |