Wirth: A Brief History of Modula and Lilith (38 KB)
The ModulaTor publication is about the programming languages Oberon-2 and Modula-2: programming examples, implementation notes, language comparisons, and language design. 72 back-issues available.
modulaware.com →In the years 1978-1980 the workstation Lilith was developed at ETH Zurich. It featured a microprogrammed processor, a high-resolution display, and a mouse. The entire software was programmed in Modula-2, a language derived from Pascal within the Lilith project. It featured the module with explicit interface specifications, and its implementation included the facility of separate compilation of modules with complete type checking. The need for a structured language with a module facility was less pronounced in the software community at large than in our immediate environment. An explanation of this requires some digression. The computing facilities available in 1977 were essentially large scale mainframes hosting sophisticated time-sharing systems, accessible only via terminals and remote satellites. The revolutionary concept of the powerful, personal workstation - the Alto computer developed at PARC - appeared to me like a revelation [4]. I was immediately convinced that there was no point in continuing development of software, except if based on and oriented towards this novel computing environment. However, such devices not being available on the market, there remained only one path to proceed, namely to design and build one on our own. Again, there was a recogized need and an idea of a solution. The project produced the workstation Lilith [5, 6]. There is no point in creating new hardware without new software. A basic operating system, utility programs, and first applications were to be developed concurrently, and therefore a programming language and its compiler were required as well. In fact, the primary incentive for designing Modula-2 was the need for a simple, allround language capable of expressing the whole range of programs needed to render Lilith into a powerful software development tool. The explicit goal was to use one and the same language for all Lilith software. Evidently, Modula and Lilith grew as a couple, and it would be futile to record the history of one without that of the other. Although a preliminary document stating certain goals and concepts of the new language was written in 1977, the effective language design took place in 1978-79. Concurrently, a compiler implementation project was launched. The available machinery was a single DEC PDP-11 with a 64K byte store. The single-pass strategy of our Pascal compilers could not be adopted; a multipass approach was unavoidable in view of the small memory. It had actually been the Mesa implementation at PARC which had proved possible what I had believed to be impracticable, namely to build a complete compiler operating on a small computer. The first Modula compiler, written by K. van Le (1977), consisted of 7 passes, each generating sequential output (intermediate code) written onto the (2 MB) disk. This number was reduced in a second design by U. Ammann to 5 passes (1979). The first pass, the scanner, generated a token string and a hash table of identifiers. The second pass (parser) performed syntax analysis, and the third the task of type checking. Passes 4 and 5 were devoted to code generation. This compiler was operational in early 1979. By this time the first prototype of Lilith, designed by R. Ohran and the author, was barely operational too. The primary design goal had been an architecture optimally tailored for interpreting M-code, the Modula compiler's equivalent of Pascal's P-code. It must be recalled that the era of unlimited memory lay still 10 years in the future. Hence, high code density was considered to be of paramount importance for complex system implementation on small workstations. Lilith was organized as a word-addressed 16-bit computer, M-code as a byte stream. Memory size was 216 words (128K bytes). The prototype was built with 4K x 1bit parts. The best choice for obtaining high code density was to define a fairly large variety of instructions, some of them rather complex, and to build the hardware as a micro-code interpreter. Eac
Excerpt from a page describing this subject · 37,928 chars · not written by Vinony
via Wikidata · CC0
Discovered by embedding cosine similarity (sentence-transformers MiniLM, 384-dim).