LO11(ID:8276/)PDP-11 port of PL-360 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 |