System Implementation Language Research Articles

Adapting large systems to small machines

An evaluation of software available on mini-computers and its adequacy was made. It led to extension of a systems implementation language to two minicomputers. The language LITTLE was chosen for its machine independence and efficiency. Techniques for code generation and storage allocation are recounted with a special emphasis on producing compact code.

Experience in the design, implementation and use of PL-11, a programming language for the PDP-11

PL-11 is a programming language for the PDP-11 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 1). 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.

Adapting large systems to small machines

An evaluation of software available on mini-computers and its adequacy was made. It led to extension of a systems implementation language to two minicomputers. The language LITTLE was chosen for its machine independence and efficiency. Techniques for code generation and storage allocation are recounted with a special emphasis on producing compact code.

Ackermann's function: A study in the efficiency of calling procedures

A six line recursive procedure is used to assess the efficiency of the procedure calling mechanism in ALGOL-like languages. The results from some 40 systems varying from ALGOL 68 and PL/I to System Implementation Languages for minicomputers are presented and compared. A hundred to one variation in performance occurs with this test, the major reasons for which are given.

SYSL

SYSL-System Description Language, which is a higer level language like FORTRAN, COBOL and so on, has been developed as a system implementation language for use by DIPS-1 operating system, a large scale OS for time-sharing services, banking control services and so on.Run-time efficiency and space efficiency of SYSL object codes are 1.11 time and 1.17 times, respectively, of those obtained from assembly language.SYSL has been used to write about 90 per cent of language processors and other processing programs of DIPS-1 OSSYSL has reduced the huge amount of time required for coding, debugging, maintaining and documenting.

The two-level approach to data definition and space management in the LIS system implementation language

It has often been remarked that surprisingly few parts of the algorithms which define an operating system require the use of unsafe, low-level language features {1}. Nevertheless, the lack of safety inherent in these parts will propagate to the whole system if an appropriate methodology is not used. It seems desirable to structure programs in such a way that parts with different safety levels are clearly separated and identifiable. The LIS solution to this problem involves the use of two language levels which are used in separate contexts. The general language is a Pascal-like language with the safety that this implies {2, 3}. On the other hand, the use of unsafe features is restricted to so-called implementation parts associated with each declaration level of the program. Several authors {4, 5, 6} have pointed out the advantages of having a two-step data definition, namely, a first step concerned with the semantic properties and a second dealing with the effective realization. In what follows we present the LIS approach to this question and show that the safety levels inherent to these two steps are different. The second step requires implementation specifications which appear in implementation parts.

A systems implementation language for small computers

This paper concerns the development of a family of higher level languages which are to serve as the target languages in the decompiling of assembler coded modules of small computer operating systems. The main objective is the design of a machine independent language to serve as the nucleus of these higher level languages, each of which will ultimately have to possess characteristics unique to the operating system for which it was designed. The work involved in the development of the nucleus language is part of a research effort intended to show that debugged assembler coded systems programs for a specific class of byte-oriented machines can be concisely represented in a higher level language and that this higher level representation can be easily moved from one machine in this class to another. It is our primary purpose here to describe the main features of the nucleus language, and, where space permits, to suggest some of the reasons why these features were included.

Current systems implementation languages

One user's experience with five current systems implementation languages is outlined stressing virtues and vices of each; the five are: FORTRAN, PASS, GOGOL, XPL, and PL360. Some criteria for future systems implementation languages are suggested; the most crucial features of a systems implementation language are (1) access to the “real” machine, (2) compatibility with existing software, (3) linguistic structure, and (4) predictability of code generator and storage management.

Reflections on a systems programming language

A particular systems implementation language, Bliss, has been in active use at Carnegie-Mellon for over two years. At this point the language has been used for several compilers, a conversational programming system, an i/o support system, a discrete event simulation system, and other diverse applications. The authors, together with others, have been responsible for the design, implementation, evolution, and evaluation of the language. Drawing on the past two years' experience this paper attempts a critical evaluation of the language - its failures as well as its successes - with an eye toward the development of future systems implementation languages.

Problems of PL/I for system programming

A group within the Computer Science Department of the IBM T. J. Watson Research Center is now engaged in the design and development of System/A, an experimental operating system to support a variety of user activities with multiprocessing hardware. PL/I has been chosen as the system implementation language. Work with the language has shown that it is very good for system programming. However, there are problems. A number of minor annoyances can be circumvented rather easily but there are a few more basic problems which often stem from the fundamental concepts of PL/I.

A hierarchy of high order languages for systems programming

The programming of systems software in higher level languages has been a subject of much interest and debate. At Burroughs the debatability of the issue has long since ceased to exist since both the operating system and the compilers for the B5500 were successfully implemented in variants of ALGOL 60. The low manpower requirements and the ease of maintenance and modification have caused all concerned with the project to accept this approach without question. This technique has the added benefit of producing more reliable software due to the greatly reduced number of lines of code required. When the decision to produce a successor to the B5500 was made, there was no controversy over the use of high level languages but considerable debate over how high a level the languages should be. B5500 ESPOL (Executive System Problem Oriented Language), the operating system implementation language, contained many “unsafe” constructs, for example, the ability to directly address memory through a subscripted reference to an array known, strangely enough, as MEMORY. This allowed coding errors to produce undesirable side effects on the system. Examination of the algorithms used in most operating systems indicated that surprisingly few routines actually require such “unsafe” tools leading to the conclusion that the proper approach to the coding of the overall systems software might be a hierarchical set of systems programming languages with varying degrees of “safety.”