MULTICS PL/I(ID:5898/mul004)Production PL/I compilerEvolution of EPL on the Multics project into a fully formed systems language According to the MULTICS team's response to the Rosin questionnaire, first available 7/69 to MULTICS Users. Other sources say earlier Related languages
References: The basis of the PL/I experience that I wish to talk about is mostly on the Multics system, which is being done as a cooperative project by the Bell Laboratories, the General Electric Company and Project MAC of MIT using the GE 645 computer which is derived from the GE 635. However, I am not giving an official Multics view but rather only my own opinion as a member of the design team. In fact, it's a preliminary view because it is still early to be certain that we have analyzed exactly what is happening. Further, one has to be cautious in forming final judgments on a language, even though it is already a de facto standard, since there still is a need for a great deal of diversity in the computing field so that different techniques can be evaluated. Extract: which compiler? which compiler? So the question was: What compiler to use when developing Multics? We chose PL/I. The reasons go somewhat like this. One of the key reasons that we picked the language was the fact that the object code is modular, that is, one can compile each subsection of the final program separately, clean up the syntax, and test it on an individual basis. This latter point seems obvious, perhaps, because object code modularity is in several languages, like JOVIAL, FORTRAN , or MAD but it wasn't in the ALGOL implementations available and it blocked us from considering it. The second reason for picking PL/I was the richness of the constructs, especially the data structures and data types which we considered to be very powerful and important features. We had a task on our hands with fairly strong requirements and with unknown difficulty. We viewed the richness as a mixed blessing, however, because we certainly were a little wary of the possible consequences. But it certainly seemed the right direction to start and maybe to err on and to cut back. As I'll get to later, it was a little too rich. Another reason for choosing PL/I was that it was roughly machine independent. Our object in doing the system has not been to compete with normal manufacturing. Instead, our object has been to explore the frontier and see how to put together effectively a system that reaches and satisfies the goals that were set out. We are trying to find out the key design ideas and communicate these to others, regardless of what system they are familiar with. Hence, a language that gets above the specific details of the hardware is certainly desirable, and PL/I does a very effective job of that. In other words, it forces one to design, not to fiddle with code. And this has turned out to be one of its strong points. Another reason that we considered PL/I was that we thought the language would have wide support. To date it has had the support of one major manufacturer. And the final key reason for PL/I was that two persons associated with the project, especially Doug McIlroy and Robert Morris at Bell Labs, offered to make a subset of it work. In addition, a follow-on contract with a vendor was arranged for a more polished version of the compiler. This is basically why we chose PL/I. We have certainly debated, somewhat casually other choices but these were the essential reasons why we picked the language. Extract: TMG and EPL The language that was used to implement EPL was TMG, short for "transmogrifier," which is a language system developed by Bob McClure. It's a clever, interpretive system specifically designed for experimental language writing or syntax analysis. However, it is not easy to learn and use and, therefore, it is hard to pick up the work of somebody else written in the language. The EPL translator was initially designed as two passes, the first one being principally a syntax analyzer and the second one basically a macro expander. The output of the second pass in turn led into an assembler which handled the specific formatting for the machine. Later a third pass was added intermediate between the first two in an attempt to optimize the object code. The quick-and-dirtyness came through when the original language subset specs had only a single diagnostic, namely, ERROR. That has been expanded so that maybe now there are half a dozen, but the only help you get is that the message appears in the neighborhood of the statement that caused the trouble. The compile rate, which was never a major issue, turned out to be a few statements per second. It has been improved a little with time, but more critically the object code that is generated has improved to a respectable 10 instructions per executable statement. (There's obviously a large variance attached to these figures.) The environment that the EPL compiler had to fit into is significant. First of all, we had adopted as a machine standard the full ASCII character set of 95 graphics plus control characters, so one of our first projects was trying to map a relationship with EBCDIC—the IBM standard. We also intended to use the language in a machine with program segmentation hardware in which programs can refer to other sections of programs by name. Fortunately, we could use the $ sign as a delimiter to allow us to have two-component names. We also expected the compiler to generate pure procedure code which was capable of being shared by several users each with their own data section who might be simultaneously trying to execute the same procedure. We also wanted to establish as a normal standard, although not a required one, the use of recursive procedures by means of a stack for the call, save, and return sequence, linkage information, and automatic temporary storage. We also wanted to allow the machine to have a feature which we've called "dynamic loading" in the sense that an entire program isn't loaded per se; the first procedure is started and, as it calls on other procedures, these procedures in turn are automatically fetched by the supervisor on an as-needed basis rather than on a pre-request basis. This, of course, is in conflict with any language which allows storage to be pre-declared by the INITIAL specification within any possible module that is ever used by the program. (This problem also comes up in FORTRAN.) We also had a feature in the machine, which we call segment addressing that allows one to talk about a data segment without having to read it in through input/output; rather, one merely references it and the supervisor gets it for one through the file system. In other words, we were trying to design a host system capable of supporting software constructs which make it easier for people to write software subsystems. External link: Online at Multics in Datamation 15(5) May 1969 view details This report summarizes all data collected in a survey of implementations of the PL/I language. An attempt was made to contact all people or groups known or rumored to be undertaking such a project. A fairly lengthy questionnaire was mailed out when a prospect was identified, beginning in August, 1967. The latest response was received in August, 1968. As is the case in most such efforts, it is likely that some projects were overlooked. In other instances, our attempts to contact people were met with no response at all, neither confirming nor denying the existence of the implementation involved. There were also a few cases in which one or more implementations did indeed exist; but their nature was proprietary and, therefore, the questionnaire was not completed. An in two cases, the individual contacted replied by stating that the supposed implementation had never existed. Only in the latter cases is the attempt at contact not included in the overall summary table. The data are summarized in four tables. The first contains the basic identification of all attempted contacts and the resulting response. The second table summarizes all questionnaires returned with respect to implementation data. The third and fourth tables relate responses to questions about the PL/I language and the dialect implemented. Responses from three questionnaires are excluded from these tables since, in the author's opinion, the dialects are more closely related to languages other than PL/I, itself. The third table summarizes restrictions found in the various dialects, while the fourth lists the extensions found in one or more dialects. This report suffers from the fact that the questions were somewhat general (e. g. , "Which features have you implemented in a manner at variance with C28-6571 -4? "), and the responses, therefore, reflect the interpretation imposed by the responder. An attempt has been made to normalize these aspects of the data, but it is clear that the result is far from ideal. in Datamation 15(5) May 1969 view details After several levels of improvement in the EPL compiler, a complete new one was developed, and is known as the MULTICS PL/I compiler, running on the GE 645 [Freiburghouse, [969]. It is felt to gen- erate good code. The new version of PL/I is not quite a superset of EPL, but was itself written in EPL using CTSS and MULTICS. Some features from EPL were omitted (e. g. , fixed point division, transfer vector declaration, free placement of some declarations)while others were implemented differently (e. g., conversion of arguments to user declared entry names, array or structure dec[arations). Among the features of PL/I which were added to EPL are the ABNORMAL, NORMAL, REDUCIBLE, IRREDUCIBLE attributes, and the compile-time macro statement INCLUDE [Honeywell]. The development of MULTICS using EPL and then continuing the development using the MULTICS PL/I compiler is a superb example of what can be done and what advantages accrue through the use of a higher level language. [...] The greatest advantage accruing from the use of PL/l was the reduction of the complexity inherent in the use of machine code for a very large system. The normal problems accruing from personnel turnover, changing specifications, and need for redesign and recoding of portions of the system were minimized through the use of the higher level language. Although the people involved did not use the phrase themselves, this author would characterize the advantage as "being able to see the forest through the trees". Several instances of redesign occurred, and the subsequent recoding was accomplished in relatively little time with great improvement in the object code. On the negative side, was relatively poor object code resulting jointly from the (inefficient) EPL compiler and also from poor ineffective use of EPL by the programmers. For example, although the GE 645 has 36-bit words, "a man declares an array of repeating 37-bit elements and the compiler dutifully does it, straddling word boundaries mercilessly." [Corbato, 1969]. in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details The language The Multics PL/1 language is the language defined by the IBM "PL/1 Language Specifications" dated March 1968. At the time this paper was written most language features were implemented by the compiler but the run time library did not include support for input and output, as well as several lesser features. Since the multi-tasking primitives provided by the Multics operating system were not well suited to PL/1 tasking, PL/1 tasking was not implemented. Inter-process communication (Multics tasking) may be performed through calls to operating system facilities. Extract: Design objectives Design objectives The project's design decisions and choice of techniques were influenced by the following objectives: 1) A correct implementation of a reasonably complete PL/1 language. 2) A compiler which produced relatively fast object code for all language constructs. For similar language constructs, the object code was expected to equal or exceed that produced by most Fortran or COBOL compilers. 3) Object program compatibility with EPL object programs and other Multics languages. 4) An extensive compile time diagnostic facility. 5) A machine independent compiler capable of bootstrapping itself onto other hardware. The compiler's size and speed were considered less important than the above mentioned objectives. Each phase of the original compiler occupies approximately 32K, but after the compiler bas compiled itself that figure will be about 24K. The original compiler was about twice as slow as the Multics Fortran compiler. The bootstrapped version of the PL/1 compiler is expected to be considerably faster than the original version but it will probably not equal the speed of Fortran. Extract: SUMMARY SUMMARY Our experiences both as users and implementors of PL/1 have led us to form a number of opinions and insights which may be of general interest. It is feasible, but difficult, to produce efficient object code for the PL/1 language as it is currently defined. Unless a considerable amount of work is invested in a PL/1 compiler, the object code it generates will generally be much worse than that produced by most Fortran or COBOL compilers. The difficulty of building a compiler for the current language has been seriously underestimated by most implementors. Unless the language is markedly improved and simplified this problem will continue to restrict the availability and acceptance of the language and will lead to the implementation of incompatible dialects and subsets. [7] Simplification of the existing language will make it more suitable to users and implementors. We believe that the language can be simplified and still retain its "universal" character and capabilities. The experience of writing the compiler in PL/1 convinced us that a subset of the language is well suited to system programming. This conviction is supported by Professor Corbat㠩n his report on the use of PL/1 as an implementation language for the Multics system. [8] Many PL/1 concepts and constructs are valuable, but PL/1 structures and list processing seem to be the principal improvement over alternative languages. [9] External link: History of Multics PL/1 in [AFIPS] Proceedings of the 1969 Fall Joint Computer Conference FJCC 35 view details Resources
|