PL/ACME(ID:5802/pla003)PL/I dialect for medical applicationsProgramming Language for ACME, where ACME system = Advanced Computer for MEdical research Developed by Wiederhold et al at Stanford Medical Research Institute: optimised subset of PL/I designed to be translated into assembler. Interesting details in the Wiederhold 2001 interview on his retirement Rosin's survey had the system described as ACME/PL, and had it writen in FORTRAN and Assembler rather than in PL/I itself Related languages
References: in Proceedings of the ONR Computer and Psychobiology Conference, Monterey, California, Office of Naval Research, May, 1966 view details in [AFIPS] Proceedings of the 1967 Fall Joint Computer Conference FJCC 31 view details in [AFIPS] Proceedings of the 1967 Fall Joint Computer Conference FJCC 31 view details INTRODUCTION The ACME compiler is a true incremental compiler operating in a system providing realtime and time-sharing services in the Stanford Medical School and some other laboratories of Stanford University. It provides the principal contact between the user and the computer in an integrated, one-language system in which both commands to the system and program statements are handled at the same level. There has been much discussion concerning the desirability of incremental compiling. We were faced with a situation where the usual alternatives - interpretive systems or remote access to batch processing - were not adequate. The system had to be powerful enough to support statistical calculations, data processing, and manuscript editing; and flexible enough to provide experiment control in a research environment. A researcher needs to get his data from his instruments to the computer, have control over parameters and identifying information, have access to previous results for comparative evaluation, and have means of presenting the information to allow him to make decisions regarding the progress of his work. In conventional computing the elapsed time for one iteration through this loop is on the order of a week. Our system and, in particular, our compiler were designed to reduce this time to minutes. Extract: CHOICE OF LANGUAGE CHOICE OF LANGUAGE There were several reasons for choosing to implement a one-language system. Since our users are obliged to do their own programming, learning to program must be relatively easy. The volume of systems code in a one-language system is less so that the compiler can be core resident, which increases operating efficiency. It is an achievable goal in a project with limited resources. We wanted to avoid contributing another homemade product to the language explosion; neither did we want to augment an existing language beyond its scope. Subsetting a defined language would afford several advantages, primarily in the areas of compatibility and communication. PL/1 offered a very powerful selection of language facilities from which to choose. It is reasonably rich in data types, has no reserved words, and relatively few arbitrary restrictions [6]. We selected a subset of PL/1 which seemed appropriate to a time-sharing environment and did not present insurmountable problems of implementation. Judged not essential for the users which we are serving were such features as recursion, decimal arithmetic, and automatic sterling conversion. For implementation reasons we omitted block structure, in relation to the scope of variables. We will now introduce our notion of incremental compilation and explain this important decision. Extract: IMPLEMENTATION IMPLEMENTATION The ACME compiler was written by one programmer working full time, and a few programmers working part time, in less than two years. This was made possible by realistic system design and by programming in a higher-level language. The system was written almost entirely in FORTRAN IV (H-Level) of IBM's Operating System/360. There are numerous advantages to coding in a higher-level language. Besides the obvioas advantages of ease of coding and checkout, writing in FORTRAN allowed us a system flexibility which machine language systems seldom achieve. Furthermore, the FORTRAN H-Level compiler provided a higher level of execution time optimization than can be found in machine language coding over such a large volume of code. Using a higher-level language also reduced the volume of documentation necessary for the project. in Morrell, A. J. H. (Ed.): Information Processing 68, Proceedings of IFIP Congress 1968, Edinburgh, UK, 5-10 August 1968 view details While the report describes the compiler adequately for those conversant with time-sharing systems, it suffers from a few oversights. For example, the authors dismiss remote access to batch-processing as being inadequate, without explaining why conversational access to batch-processing for conversational execution was not considered. As an implementational consideration the designers omitted block structure and the concomitant problem of scope of variables, on the grounds that there were no known symbol table techniques to solve the problem. A paper presented at this same conference by Peccoud et al. seems to represent a satisfactory approach in an interpretive system [ See PECCOUD, M.; GRIFFITHS, M; AND PELTIER, M. "Incremental interactive compilation." Proc. IFIP Congress 1968]. Object code is not saved between runs. "Our experience has shown that direct compilation of non-relocatable code can be nearly as fast as the loading of relocatable code containing many cross-referencing pointers." This is not surprising, with a core resident re-entrant compiler. The authors make a valid point in favor of writing compilers in high level languages (FORTRAN IV-level H in this case). A follow-up report after some extensive experience with various classes of programs and real-time gear interfaces would be most informative for readers interested in timesharing software. in ACM Computing Reviews 9(11) November 1968 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 ACM Computing Reviews 9(11) November 1968 view details in IEEE Computer Group Digest, June 1969 view details in Proceedings of the IBM Japan Computer Science Symposium: Research and Computer Systems, IBM, Japan, November 1969 view details in Proceedings of the San Diego Biomedical Symposium on Computing On-Line, San Diego, April 1970 view details in Proceedings of the San Diego Biomedical Symposium on Computing On-Line, San Diego, April 1970 view details in Proceedings of the San Diego Biomedical Symposium on Computing On-Line, San Diego, April 1970 view details in Proceedings of the San Diego Biomedical Symposium on Computing On-Line, San Diego, April 1970 view details in Proceedings of the San Diego Biomedical Symposium on Computing On-Line, San Diego, April 1970 view details in Proceedings of the San Diego Biomedical Symposium on Computing On-Line, San Diego, April 1970 view details in [ACM] Proceedings of the 1972 Annual Conference of the ACM view details What piece of work of yours are you the most proud of? [It’s] something I did before becoming a faculty member: The ACME time-sharing system that I built for the [Stanford] medical school. What was special about [the ACME system] at the time that you built it? It was very well integrated, so that, [for example,] the editor was just a function of the compiler. It was a one-language system; we implemented a subset of the PL/1 language, which turned out to be very teachable. The technology was interesting in itself: it was an incremental compiler, of which there are not very many instances [in existence], but which are a nice balance betyween a traditional compiler and an interpreter. The way it works is that every line of PL/1, whether it’s part of a statement or multiple small statements, gets compiled but then inserted into a list structure. So there is no inter-statement optimization, but each individual statement is fully compiled. And later, if [the user wants] to change a statement, we simply change the list stucture---so we can insert new statements, take out existing statements. The only thing [the user] cannot change [in a program is to] make major TYPE changes. [For example, the user] cannot change a numeric value to a string, because there is too much code [that would need recompilation]. [The ACME compiler’s flexibility] was very important for the real time aspects of the system. The system did real time data acquisition. [When a problem arose with a program, the ACME system] allowed [the user] to change [the program] while a [medical] experiment was [still] going on, [without] cancelling the experiment (which often involved animals, etc.) [or] losing data. [When did you build the ACME system?] I started in late 1965 and it was running by 1967. We bought an outrageous amount of memory for the time. One megabyte of memory. It was so big that I remember that the truck driver, coming from Poughkeepsie, would call me every night to tell me how far he had gotten with that huge memory. The people who used [ACME]---what kind of a system were they used to? Some of its features were still novel today, but back then it must have been much more… It was the first computer that most of them had used! And later, in fact, I met medical people who went to new and better systems, and they were frustrated that they would lose data when there was an error in their program, [and have] to start [their experiment] over. in SIGMOD Record 30(4) December 2001 view details |