LP-20(ID:8274/)CII 10020 port of PL-360Port of PL360 for the CII 10020 (XDS Sigma 2), sister system for the LP-70 Related languages
References: INTRODUCTION PL-II is a programming language for the PDP-II family of computers designed and implemented as part of the OMEGA Project at CERN (the European Organization for Nuclear Research). Its purpose is to provide an effective tool for both physicists and systems programmers to use in building real-time data acquisition systems that are online to high-energy physics experiments. It is a fairly typical member of the PL-class of programming languages (44) which are based on the initial design of PL360 (41) (see Table i). Each of these languages represents a linguistic model of its specific machine architecture, thereby providing a Systems Implementation Language (SIL) that is extremely efficient on its target machine, yet is also highly effective for human programmers to use. The need for such a tool is obvious on all computer systems, but especially on minicomputers, where most applications are in fact "systems programs". For example, in any data acquisition environment the distinction between "user" and "operating system" largely disappears--the user's prime concern is to handle time-dependent sequences of events involving the manipulation of special I/O devices through direct status checking and data streaming--all functions which are usually buried in the operating system of conventional computing systems. This paper discusses four years of experience with PL-II, especially as this relates to the general topic of SILs on minicomputers. Extract: Program Development Systems Program Development Systems In July, 1971, the OMEGA Project computing facility (34) was defined as one central medium-sized computer (XDS Sigma 7) and several on-line minicomputers (PDP-II/20), one per experimental grouP using the OMEGA magnet and detector system. This design concentrated the computing power in one big machine, yet permitted each experimental group maximum flexibility and independence through the use of its own minicomputer for setting up, debugging, and driving all its own on-line electronics. In order to keep costs low, each minicomputer was a "bare" machine-- 8K core, paper tape I/O, and teletype. With no disk or magnetic tape, programdevelopment on the minicomputer itself was unfeasible, and with the conve~ientavailability of the more powerful Sigma 7 it was also unnecessary. Therefore the PL-II compiler was implemented as a Fortran program running on the Sigma 7. The output of a compilation is a relocatable object module in the format accepted by the Sigma 7 linkage editor. Any number of PL-II modules can be compiled separately, stored in libraries on the Sigma 7 disks, and then linked together on the Sigma 7 to produce an absolute core image. In the early stages of OMEGA operation, this core image was punched onto paper tape and carried to the nearby PDP-II's for loading and execution. Later a high-speed (one megabyte) computer-to-computer data link was established that enabled the PDP-I1 to be loaded directly from the Sigma 7, obviating the need for paper tape. This method of program development for minicomputers proved to be an extremely productive one. The advantages are obvious--all program development tools available on the big machine are available "free" to the minicomputer user. Most large systems, such as the Sigma 7, represent a considerable investment by the manufacturer in development tools, such as file system capabilities, library processors, linkage editors, etc., that are orders of magnitude more powerful and easier to use than the support software (if any) provided with the minicomputer. Furthermore, enhancements to the central system, automatically benefit the program development process for the minicomputer user, and it is often easier to justify expenditures for such improvements to central systems. For example, the ORION system (36) developed for the OMEGA system enabled the minicomputer programmer to write, compile, debug and use programs for either the PDP-II or the Sigma 7 or both without ever leaving the teletype of his minicomputer. With program development unified to this extent, the user has to learn only one set of control cards and/or commands for one set of compiling, linking and loading facilities. This in turn encourages him to utilize the power of the linked system without going through the agony of learning a maze of contradictory details for two different systems. In 1974 the PL-II compiler was rewritten in itself to run on the PDP-II. This made PL-II available to PDP-I1 users that did not have convenient access to a large Fortran machine, and enabled them to use a PL-II compiler with the DOS and RSX operating systems for the PDP-11. The Fortran version of the compiler was modified to produce relocatable object modules in the DOS/RSX formats (in addition to the Sigma 7 format), but the problems of transporting these modules to machines not connected by data links were unexpectedly nontrivial, due primarily to the lack of a single common storage media that could be handled easily by both systems (at that time, RSX-IID did not support paper tape). Extract: Language Design Language Design The primary aim of PL-II was to become the single language for all programming on the OMEGA Project PDP-II's. In order to satisfy the demands of systems programuners, the language had to allow programmer access to all features of the hardware and the I/O devices. In order to satisfy the demands of physicists who were writing the data acquisition programs, the language had to have high-level structures typically found in most applications-oriented languages, such as Fortran. A con~mon technique for achieving such a goal is to implement a restricted subset of a highlevel language (a popular choice today is PL/I), but although this was considered the following are reasons why it was rejected as a viable approach for a minicomputer SIL. Many high-level languages ass%tme the existence of a run-time support system to provide a convenient environment for the progran~er. In particular, storage management, data formats and conversions, interrupt control and I/O device control (or lack of it) are implied parts of almost all highlevel languages today. But it is precisely for explicit programming of these tasks that we are designing the minicomputer SIL in the first place. Even assuming we could tolerate some minimal runtime package written in assembler, most highlevel storage management schemes, and especially the manner in which I/O devices are treated in high-level languages, are totally inappropriate to the realities of minicomputer hardware. Explicit interrupt management is essential to the data acquisition prograrmner, but what highlevel language accurately models the existing hardware interrupt structure of today's minicomputers? Data acquisition systems in particular often contain modules that must respond to interrupts and non-standard I/O devices in a highly time-dependent manner. In such circumstances even innocuous conventions in the progra~aning language, such as the automatic saving and restoring of all registers on each subroutine entry and exit, may be too time consuming, since few minicomputers have a single "save status" instruction. This convention may also be totally inappropriate, since only a few of the registers may be used in the interrupt service module. For example, the incredible expense of subroutine entry and exit in the PDP-II version of the SUE language (22) could never be tolerated in a high-energy physics experiment where the computer is alreadythe slowest piece of electronics in the data acquisition system. In addition to the advantage of programmer familiarity with the language, upward compatibility and portability can be claimed for programs written in the language subset. It would seem, however, that many minicomputer applications, especially data acquisition systems, are dedicated systems with low probability of ever being transported to another computer, since then many of the non-standard I/O devices would have to be redesigned as well. Furthermore, most minicomputer programs are designed to be aware of their real-world environment and respond to it in a highly context dependent manner. They are often tailored to a specific hardware configuration in which generality must be sacrificed in order to "fit" into the minicomputer. It is, therefore, unrealistic to expect that one would place a ~igh premium on getting the same program to run on another computer with a totally different environment. Many of the data structures and data referencing techniques employed in today's high-level languages are inappropriate to minicomputer hardware. In this regard the PDP-II with its eight hardware addressing modes is a particularly good example. Use of this rich set of addressing modes requires data structures and access algorithms that refer to data items, whether of the same type or not, through pointers that are incremented and decremented in a sequential fashion. Furthermore, these pointers must be maintained in registers if code size and execution speed are to be minimized. Conventional high-level language indexing techniques do not map well onto this aspect of the PDP-II hardware. Neither do the Pascal-style (42) field-selector techniques in which items within a structure are referenced by symbolic offset names. Therefore new high-level access techniques must be developed. But then the "subset" is no longer a true subset, since it contains language extensions, and programmers using both the original and the augmented subset languages will find the differences frustrating. Hence the intended "benefits" of subsetting (familiarity, upward compatibility, etcetera) are lost anyway. A final important consideration is the time and effort expended in implementing the SIL, since for most projects, especially minicomputer projects, producing the programming language is not the primary objective. Rather than spending inordinate amounts of effort trying to implement a subset of an existing, rigidly specified language that may not map well onto one's hardware, the language designer will have a much easier task if all aspects of the language specification are flexible. The first version of PL-II was in the hands of users within four months of its inception, including the first version of the user's manual (35), and this early availability was much more important to user acceptance than any fancy language features it might have contained, since development and test of both the software and the user-built I/O devices for the minicomputers could not proceed very far without the programming language. There is little benefit in producing a super tool after completion of all the tasks that might have used the tool. Extract: The PL-11 Language The PL-11 Language PL-11 was designed as a "new" language, but one modeled closely after PL360 (41). As can be seen from the sample program in Figure i, it is a typical example of the many PL-type languages based on PL360. All machine registers have symbolic names that are visibleto the programmer, and they must be explicitly allocated and operated upon by the prograImner. The language provides a static block structure with name scoping very similar to ALGOL 60's. All variables must be declared of a certain type, and they can be accessed symbolically only within the scope of the block containing their declaration. The storage allocated to a variable is assigned at compile time, and is permanent for the life of the program. Hence any variable can be initialized, and will retain its most recently assigned value across block or procedure exit and reentry. In this sense variables are automatically the "static own" variables of ALGOL 60. Constants can also be given symbolic names through declarations. Procedures can be declared in any block, and can be nested to any depth. Provision is made for defining GLOBAL procedures and data segments, and for referencing EXTERNAL procedures and data segments symbolically. Thus many separately compiled PL-11 program modules can reference each other and their common data segments symbolically. Each PL-11 module is compiled into relocatable binary form, and the interface conventions permit PL-11 modules to be linked with modules written in PAL-I1 or Fortran as well as PL-11. The highlevel control structures include IF - THEN, IF - THEN - ELSE, FOR, FOR - WHILE, WHILE, and CASE, all of which can be nested to any depth in any combination. GOTO's and labels are also permitted. Expressions are very low-level and are evaluated strictly left to right, including the assignment operator (=>), with no parenthesization or operator hierarchy. Dyadic operators are written in infix notation, monadic operators in postfix, and all operators map onto the machine instruction set in an obvious manner (Table 2). Table 3 lists special expressions that are mapped by the compiler onto single hardware instructions. All variables are typed, and no mixed-mode operations, except for assignment, are allowed, since the hardware does not support automatic type conversion. ~ The only data structures provided are linear arrays and stacks, and all subscripts must be a register and/or a constant, again due to hardware limitations. The above features, with minor variations such as the left-to-right assignment operator, are generally con~non to all PL-type languages, whereas the following appear to be unique to PL-11. PL-11 does not allow the progranuner to include any "inline" assembly language instructions, since all PDP-II instructions are representable in the syntax of the language. Any expression consisting of all constants (whether symbolic or not) is evaluated at compile-time. This feature is extremely useful for parameterizing programs without losing run-time efficiency, and is one found in almost all assemblers (where it is used primarily for address calculation), but is absent from almost all hlgh-level languages for no apparent reason other than oversight. In addition to regular procedures, interrupt procedures can be defined for any kind of hardware or software interrupt or trap. In order to simplify the interface between the on-line minicomputers and the experimental electronics, CAMAC, the international standard for interfacing electronic components (12), was adopted for all equipment used in the OMEGA Project. Presence of a standard interface enabled us to incorporate the conventions for using that standard into the syntax of PL-11. These features enable programmers to give symbolic names to CAMAC variables and functions, and then to utilize these names in the same manner as normal variables and functions. The physicist can therefore program operations on his external electronics in an extremely simple, obvious manner, yet the code generated by the compiler is exactly what is needed to drive the CAMAC interface--there is no efficiency loss. Through the use of compiler control cards placed in the input deck the programmer can control pagination of his program listing (another feature regrettably lacking in most high-level languages) and the particular object-time hardware configuration on which the compiled code is to run (which model PDP-II, what extra hardware it has, such as floating-point, and which type of CAMAC interface is in use). In addition, the INCLUDE control card allows symbolic PL-11 source statements from other files to be included anywhere in the deck. Thus procedure libraries and/or data base definitions can be incorporated symbolically at compile-time, as well as at link-edit time as in more conventional systems. in SIGPLAN Notices 11(04) April 1976 view details PL-11 serves as the standard programming language on PDP-lls in CERN's Onega Project, a multiparticle spectrometer whose data acquisition system consists of a number of PDP-lls on-line to a CII 10070. Extract: PREFACE PREFACE The PL-11 compiler was written by Bob Russell, during the time he spent at CERN as a Fellow. The implementation of the compiler went through two major steps, each of which had a minor iteration. So, version 2 was the first definitive release of the compiler, and version 4 is that which is currently available. Boh wrote two notes which were published internally to the Onega Group, the first of which described version 2 as it then was, and the second of which described the changes, additions and improvements which went to make up version 4. Unfortunately, Bob did not have time, before he left CERN, to put these notes together to make a single paper. That task has fallen to the present editor, and the two notes mentioned above have been used as the basis of this document. The PL-11 compiler currently executes as a cross-compiler on the CII 10070 used by the Onega Project. It is written in FORTRAN. Versions are available to run on other machines with FORTRAN capability, but they are not completely guaranteed. Requests for FORTRAN versions, accompanied by a \" magnetic tape, should be sent to: CERN Program Library, DD Division, CERN, 1211 Geneva 23, Switzerland. and should indicate in which density (9-track, 800 or 1600 bpi only) the tape should be written, and which version is required (IBM 360/370, CII 10070, CII IRIS 80, UNIVAC 1100 series, CDC 6000/7000 series, Honeywell 6000 series, XDS SIGMA 5/7). The tape will then be returned with [hopefully) sufficient documentation to allow installation of the compiler. A nominal fee will be charged to cover copying, packaging and postal charges. CERN accepts no responsibility for the correctness or otherwise of these versions, and will not undertake to update or maintain them, but would be grateful for any comments, corrections, or assembler versions of critical routines. These should be addressed to the above. All such changes would become the property of CERN. A note is available from the CERN Program Library describing its functions and giving additional details of the conditions of distribution of programs. A version of PL-11 exists also for the PDP-11, itself written in PL-11; this runs either under the RSX-11D or DOS systems. Enquiries concerning this version should also be addressed to the above. Extract: INTRODUCTORY DESCRIPTIONINTRODUCTORY DESCRIPTION INTRODUCTORY DESCRIPTION PL-11 is a language for programming the DEC PDP-11 computer, designed and implemented by the author as part of the Omega Project at CERN. It belongs to the class of computer languages which has been variously classified as "structured assembler", "high-level assembler", "intermediate language", or "low-level language". It is modelled after PL-360, the first language in this class, and is intended to fill the gap between high-level languages, such as FORTRAN and ALGOL, which are easy to learn and program but are inefficient and cumbersome for small computers and "systems programming", and the basic symbolic assemblers, which are very difficult to learn and program, primarily because of their awkward notation, but are essentially "as efficient as possible", because of their closeness to the basic machine hardware. PL-11 is designed for convenient programming in an ALGOL-like style and notation, but with minimal sacrifice of the efficiency possible in basic assembler code. It is a tool for utilization by both the efficiency-conscious systems programmer and the applications programmer who wishes simply to get a job done. In both cases the language design encourages a clear, concise programming style in which programs are easy to read and modify, and the program listing itself can serve as a convenient form of documentation1 for the algorithm being programmed. Extract: Background Background In 1968, Wirth published a paper [JACM #15 (1968] p.37] describing PL-360, "A Programming Language for the IBM 360". As originally designed, this language was intended primarily as a tool in which to write an ALGOL compiler for the IBM 360 computer, since the standard IBM assembler was virtually unusable, owing to an extremely slow assembly speed, an awkward, obscure notation, and the difficulty of dealing directly with the organization of the IBM 360 addressing mechanism and instruction repertoire- It was soon recognized, however, that this language was exactly the tool that had long been missing in systems work, as well as all other applications previously requiring assembler coding, because of its convenience to the programmer, its compilation efficiency, and the efficiency of the code produced. To illustrate, the compiler (which is itself written in PL-360) will recompile itself on an IBM 360/67 using OS at the rate of 6000 cards per minute (spooled I/O), and on an IBM 360/30 using DOS at the rate of 1200 cards per minute [i.e. the speed of the on-line card reader!). Although originally designed for stand-alone use of the IBM 360, PL-360 was quickly modified to operate under the standard IBM operating systems, and since then has been further modified to operate in a time-sharing environment. Following the precedent set by PL-360, several other languages have been designed with the same objectives. PL-516 was developed by Bell and Wichmann [Software, Vol. 1 (1971), pp. 61-72] f°r tne Honeywell DDP-516 computer at the National Physical Laboratory, England. Although considerably more "primitive" in its basic features than PL-360 (largely because of the primitiveness of the DDP-516 hardware), the authors conclude: "A high-level assembly language for a small computer has been shown to be entirely feasible and to provide an easy method of exploiting the hardware without becoming entangled in machine code" [p. 71). They also state: "We would therefore recommend the use of ALGOL-like assembly languages for computers having 8K 16-bit words...", which is particularly relevant to the 8K 16-bit PDP-11 In Munich, Germany, a group at the Technische Hochschule has developed a language called PS-440 for their Telefunken TR-4 and TR-440 computers. This language includes features absent in PL-360, and notationally is modelled after ALGOL 68 (PL-360 notation is similar to ALGOL 60). This was designed as a tool with which to write operating systems, and has proved extremely useful in that as well as other areas. A lesser known development is the languages LP-20 and LP-7O, developed in France for the CII 10020 and CII 10070 computers, respectively. These are very similar syntactically to PL-360, but do not seem to be widely known outside of France. Extract: Objectives Objectives PL-11 is the result of a design and implementation effort to fulfil the following objectives [not necessarily in order of importance). a) The syntax of the language should be easy to learn, to read, and to use- In particular, the notation should be similar to FORTRAN or ALGOL, and should completely avoid the awkward, unnatural notation of assembly language. b) The language should permit full use of the facilities provided by the PDP-11 hardware. In particular, all registers, storage cells, and machine operations should be accessible to the programmer's control. c) The code generated by the compiler should be predictable from the language constructs. In particular, nothing should be "hidden" from the programmer, so that it should always be possible to determine from the PL-11 language specifications exactly what code is produced by each language construct. d) The code generated by the compiler should be efficient. To accomplish this in a manner consistent with points (b) and (c) requires that the language be designed to reflect accurately the capabilities of the hardware, so that each language construct would generate a minimal number of instructions. Optimization, except in a few special, well-defined cases, is then the task of the programmer, not the compiler. e) The language should allow the programmer full use of the facilities provided by the PDP-11 software environment. In particular, communication with any monitor, and with routines written in assembler language, should be easy and straightforward, f) The compiler should be written in FORTRAN for the CII 10070 computer. As much as possible, use of the special features of the CII FORTRAN should be avoided so that the compiler could be transported to other machines with FORTRAN capability. g) The compiler should generate the code in the form of relocatable object modules acceptable to the CII SIRIS7 operating system. This would enable the programmer to make full use of the disk storage, library, and linkage editing facilities of the CII system, and would also permit PL-11 programs to be easily combined with programs produced by A. Jeavons' PAL-11 assembler that runs on the CII 10070, thus satisfying point (e) above. h) The compiler should be reasonably efficient, and not require inordinate amounts of time or space on the CII 10070. i) The language should be well documented, so that non-professional programmers can learn and program in PL-11 without a knowledge of the DEC PAL-11 assembly language, and with only a rudimentary knowledge of the PDP-11 hardware. Extract: Philosophy Philosophy As in any design effort, the product will reflect to a large extent the author's philosophy and experience. PL-11 shares the same basic philosophy as PL-360. This philosophy can be summarized as follows: a) The language should do everything possible to encourage a clear, comprehensible programming style. As far as possible the petty details of assembly language notation, the fixed format restrictions of FORTRAN and assembly language, and FORTRAN'S artificial restrictions on identifier length and first letter should be abolished. b) The rules for writing syntactically correct language constructs should be as simple and general as possible. Exceptions and special cases should be minimal, if not nonexistent. c) The language should include a rich set of structured facilities, so that GOTOs and labels can be virtually eliminated. This improves enormously the readability and understanding of a program, especially for those who must use or modify a program they did not write. d) The language should not permit automatic defaults, such as are found in FORTRAN and abound in PL/I. Missing items serve to decrease the program's readability and increase the burden on the programmer to remember annoying details, (They are usually remembered incorrectly, or in a confused and muddled state that requires constant recourse to the language manual to determine "what happens when".) If a language is clear and concise, there is no need for someone using it to "leave things out". Invariably the "things" that get left out are poorly designed or ill-conceived in the first place. e) A program is written to operate on data, not on itself. Therefore programs should not be self-modifying, since this often involves programming "tricks" which take longer to debug (as well as making the debugging more difficult), and which make the resultant program totally incomprehensible to anyone but the author (and sometimes even to the author after a few weeks). In addition, self-modifying programs can be neither reentrant nor recursive. Ideally the machine hardware would provide a mechanism to protect program code from all forms of access except instruction execution, but this only exists on the bigger PDP-lls. PL-11, however, contains no language components with which a programmer can explicitly modify the code generated. f) The language should include a convenient method of allowing and encouraging local variables and local procedures, so that their precise area of interest within a program can easily be ascertained. For this reason, PL-11 is a block-structured language similar to ALGOL 60. g) The compiler should produce meaningful diagnostic error messages. The cryptic, single-letter "flags" generated by most assemblers are totally useless. Although not always possible, the compiler should pin-point the exact cause of the error in such a way that its correction should be obvious to the programmer. h) The keywords of the language syntax should also be reserved words. This means that each time the word appears in a program, it will always have the same precise meaning. This not only avoids the complicated syntactic analysis needed to find keywords from context (such as is needed in FORTRAN), but eliminates the obscure "tricks" that only serve to confuse the programming style in languages like FORTRAN or PL/I, where keywords are not reserved (for example, using a variable named IF or DO in FORTRAN). The number of keywords, however, should be kept to a minimum (unlike COBOL). i) The language syntax should be expressible in a precise notation, such as Backus-Naur Form. This tends to reduce errors caused by "misinterpretation" of imprecise English explanations, and also defines exactly what is and is not allowed in a manner that is impossible in a natural language explanation. in SIGPLAN Notices 11(04) April 1976 view details |