Jensen and Fraser(ID:6988/)Unpublished systems language by P.D. Jensen and A.G. Fraser, influential on LIL Related languages
References: Memorandum for File LIL is a Little Implementation Language for the PDP-11 family of computers. Is is little in the important sense that there are very few constructs and combining rules, and fewer exceptions. Its is an implementation language, which means that it is possible to express any of the code needed to implement an operating system including I/O drivers, interrupt routines, and transfer tables. Nevertheless it remains a moderately high-level language, with the improved readability and reliability that one expects from avoiding assembly-language level coding. Introduction There is a broad gap between the fanciest macro assemblers and the simplest system implementation languages (SILs), a gap that needs filling. No matter how elaborate an assembler is, it is still just an assembler, with all the limitations on productivity attendant on writing code at too detailed (and unstructured) a level. SILs, on the other hand, seem to impose a layer of insulation between programmer and machine that causes more trouble than benefit in an environment where program size and execution time are very important, as in mini and microcomputers. What is desired, then, is a language that lets one talk about the matters that concern systems level programmers, but at a level that permits economic expression and encourages the well structured coding style we now know to be important It is no surprise that such languages are not common. People who think in terms of high-level languages have traditionally been problem-oriented; people who write systems have been reluctant to yield control of code generation to a language processor. It is only recently that, thanks to the success of some of the earlier SILs,'the use of compilers has earned some grudging respect from system writers. The cobbler's children are always the last to get shoes. This paper describes a compiler, for the PDP-II family of computers, that lies in this region. It can be considered a narrative assembler, in the sense that the user knows rather precisely what code is generated but can specify it with an economy of notation. It can also be considered a little implementation language, because it deals with multi-line, nested control structures rather than line-at-a-time code, and because it uses data type attributes to help direct the generation of instructions. The LIL language was defined in Backus-Naur, which was used by a compiler-compiler to produce a parser. The parser was combined with semantic routines written in the SIL called C (developed by Dennis Ritchie) running under the UNIX operating system (Ritchie, 1974). Significant portions of the LIL compiler were subsequently rewritten in LIL to prove its effectiveness, and the resulting language was used to help write a small PDP-II/10 operating system at Bell Labs. The compiler is one-pass and produces object code that may be freely intermixed with that of C or the UNIX assembler. In its final form, LIL probably most closely resembles Wirth's PL/360 (Wirth, 1968), in that it is a structured, machine dependent language with data types. Its control flow syntax, however, is modeled closely after that of C, for the simple reason that C was successful and there was no good excuse for introducing new notation. A number of other ideas were carried over from an earlier (unstructured) language written by A. G. Fraser and P. D. Jensen for the GTE Tempo I (unpublished), Extract: Salient Features Salient Features What makes LIL unique, and uniquely suited for minicomputer programming, is the way its various design features work together to do what is wanted without also doing many things unwanted. But to understand the language as a whole, it is necessary first to understand its parts. Here are its principal concepts, taken separately: - The data types of the language corresponds rather directly to the addressing Nodes of the PDP-II. - Arithmetic expressions describe the data manipulation code to be generated. - The compiler will not, however, accept an arbitrary combination of operands with an operator. While it is not a rigorous rule, it is generally true that at most one instruction will ever be generated for each infix operator. That way the user is assured that his code will not puff up unmanageably in translation, so he can remain aware of the limitations of the machine and still have a uniform notation for describing what is possible. (The "at most" part of the rule leaves the door open for selective optimization.) - Conditional expressions determine the conditional branches to be generated in control flow statements. These can be relational - One final feature worth particular attention is the compile time expression. Enclosing an expression in double quotes instructs the compiler to do the arithmetic right away instead of generating run-time code. Extract: Evaluation Evaluation The use of LIL makes for very readable code that is much easier to write, maintain and modify than assembly language. Despite its considerable power in some dimensions it is indeed a little language -- the conventions can be summarized in just a few coherent rules and the compiler itself comprises less than a thousand lines of code. More important, it requires n_o_o runtime support and permits the user to write code at a high level with no sacrifice in space or speed. For many mini- and microcomputer software development projects it appears to be well suited. LIL is, however, a failure. Its stiffest competition at Bell Labs is the language C, which is higher level and machine independent. Every time it looked like C was too expensive to use for a particular project, LIL was considered. But almost every time, it proved easier (and more rewarding) to improve C, or its runtime support, or the hardware, than to invest time in yet another language. LIL is superior to assembly code, to be sure, but there are few remaining crannies where C has not penetrated. Since C compiles to assembly language, why not just use the assembler to handle the few hundred lines of intractable code? It has to be around anyway. Why not indeed? A machine independent language is always superior -- even for writing machine dependent code (it's easier to find trained programmers) -- so long as the overhead can be endured. It is clear now that writing straightforward code and then measuring it is the formula for the best end product. At worst there will be 5-15 per cent overhead, which is seldom critical. Once system writers become mature enough to recognize this basic truth, they gravitate naturally toward machine independent SILs. If there is a role at all for languages like LIL, it will be in microprocessors and very small minicomputer configurations. Not so much because the need is more legitimate but because the desirability of a SIL such as C will be more slowly recognized. Otherwise it looks like the little implementation language is an idea whose time has come -- and gone. External link: Another online copy in SIGPLAN Notices 11(04) April 1976 view details |