System Implementation Language Research Articles

Архітектура та функціональні можливості системи підтримки прийняття рішень СПОР

The peculiarities of the design, development and operation of the decision-making support system SPOR are considered. The architecture of the system is presented and the choice of the system implementation language is justified. Two functionally oriented environments of the system SPOR are considered, each of which is aimed at solving specialized tasks of creating and processing electronic action plans. The functional capabilities of the component subsystems of these environments are analyzed in detail and the expediency of using the decision-making support system SPOR to solve the problems of operational management of emergency response in situational centers is substantiated.

An Attack Surface Metric

Measurement of software security is a long-standing challenge to the research community. At the same time, practical security metrics and measurements are essential for secure software development. Hence, the need for metrics is more pressing now due to a growing demand for secure software. In this paper, we propose using a software system's attack surface measurement as an indicator of the system's security. We formalize the notion of a system's attack surface and introduce an attack surface metric to measure the attack surface in a systematic manner. Our measurement method is agnostic to a software system's implementation language and is applicable to systems of all sizes; we demonstrate our method by measuring the attack surfaces of small desktop applications and large enterprise systems implemented in C and Java. We conducted three exploratory empirical studies to validate our method. Software developers can mitigate their software's security risk by measuring and reducing their software's attack surfaces. Our attack surface reduction approach complements the software industry's traditional code quality improvement approach for security risk mitigation and is useful in multiple phases of the software development lifecycle. Our collaboration with SAP demonstrates the use of our metric in the software development process.

The development of the C language

The C programming language was devised in the early 1970s as a system implementation language for the nascent Unix operating system. Derived from the typeless language BCPL, it evolved a type structure; created on a tiny machine as a tool to improve a meager programming environment, it has become one of the dominant languages of today. This paper studies its evolution.

The LADY programming environment for distributed operating systems

The LADY programming environment has been developed to support the design, implementation, testing, debugging and monitoring of distributed systems with special focus on operating systems. This paper describes the structuring model of the system implementation language LADY. In LADY, a distributed system is viewed as a collection of cooperating objects connected through typed interfaces. The language offers dynamic modifications of the program structure such as generation and deletion of objects and their interconnections as well as migration and checkpointing of objects. Further features include the extensibility of programs and recursive definition of objects. The structuring facilities of LADY are demonstrated by an example and experiences with the language are discussed.

Tools for distributed programming in the INCAS project

In the INCAS project a programming environment for distributed system has been developed. It consists of the distributed language LADY encompassing facilities to implement distributed operating systems, and a set of tools supporting the design, implementation, rapid proto-typing, debugging, testing, and monitoring of LADY programs. This paper describes the system implementation language LADY and the major components of the programming environment.

Key Concepts of the INCAS Multicomputer Project

This paper gives an overview of the INCAS (INCremental Architecture for distributed Systems) multicomputer project, which aims at the development of a comprehensive methodology for the design and implementation of locally distributed systems. A structuring concept for distributed operating systems has been developed and integrated into the system implementation language LADY. The concurrent high-level programming language CSSA, based on the actor model, has been designed for the implementation of distributed applications. A substantial effort in the INCAS project is directed towards the development of a distributed test methodology. An experimental system has been implemented on a network of ten MC68000 microcomputers. Preliminary experience with the methodology has been gained from a small number of prototype applications.

Non-technical issues in acceptance of SILs

Technical issues in Systems Implementation Language (SIL) design are comparatively well understood. However, some major factors in the choice of a SIL for a given project are not related to the technical merits of the language. They are: availability of a "good" implementation, programmer trainability, and existence of a user community.

A LIS compiler for GCOS‐7

AbstractThis paper describes the implementation of a LIS compiler for GCOS‐7. LIS is a high level system implementation language developed at CII‐Honeywell Bull during the middle 1970s, and experience with the language and its implementation have largely influenced the design of Ada. The design of the compiler was particularly aimed at efficient code generation. Design decisions concerning the run‐time organization in relation to procedure call and separate compilation are discussed. The structure of the compiler is described. The articulation between the different phases of the code generator is emphasized. Experience with the bootstrap is related.

Abstraction in the Intel iAPX-432 prototype systems implementation language

Abstract : This report describes the abstraction mechanism of a prototype systems implementaiton language for Intel's iAPX-432 microprocessor. Full exploitation of the 432's facilities places many demands on a language intended for systems implementation. The 432 is a capability-based machine, with hardware-enforced typing of large objects, dynamically instantiated domains (i.e., packages), hardware-enforced information information hiding (seals), and hardware-supported, software-defined access-rights (trademarks). The prototype language's support for these facilities is described in this project.

Empirical analysis of the mesa instruction set

This paper describes recent work to refine the instruction set of the Mesa processor. Mesa [8] is a high level systems implementation language developed at Xerox PARC during the middle 1970's. Typical systems written in Mesa are large collections of programs running on single-user machines. For this reason, a major design goal of the project has been to generate compact object programs. The computers that execute Mesa programs are implementations of a stack architecture [5]. The instructions of an object program are organized into a stream of eight bit bytes. The exact complement into of instructions in the architecture has changed as the language and machine micro architecture have evolved. In Sections 3 and 4, we give a short history of the Mesa instruction set and discuss the motivation for our most recent analysis of it. In Section 5, we discuss the tools and techniques used in this analysis. Section 6 shows the results of this analysis as applied to a large sample of approximately 2.5 million instruction bytes. Sections 7 and 8 give advice to others who might be contemplating similar analyses.

Empirical analysis of the mesa instruction set

This paper describes recent work to refine the instruction set of the Mesa processor. Mesa [8] is a high level systems implementation language developed at Xerox PARC during the middle 1970's. Typical systems written in Mesa are large collections of programs running on single-user machines. For this reason, a major design goal of the project has been to generate compact object programs. The computers that execute Mesa programs are implementations of a stack architecture [5]. The instructions of an object program are organized into a stream of eight bit bytes. The exact complement into of instructions in the architecture has changed as the language and machine micro architecture have evolved. In Sections 3 and 4, we give a short history of the Mesa instruction set and discuss the motivation for our most recent analysis of it. In Section 5, we discuss the tools and techniques used in this analysis. Section 6 shows the results of this analysis as applied to a large sample of approximately 2.5 million instruction bytes. Sections 7 and 8 give advice to others who might be contemplating similar analyses.

Embedded system design with ada as the system design language

Recent research in software engineering has produced a number of techniques for structuring an understanding of systems. Many of these techniques are applicable to the design of embedded computer systems and produce designs whose structures are easily expressible in the ada language. This language is itself structured so that the design of a system can be expressed independently of its implementation. Thus ada can be a useful system design language (SDL) with these techniques. This paper describes the software design problem in the development of embedded computer systems. It shows how ada can be used as an SDL, as well as a system implementation language. The essential point is that as an SDL ada encourages designers to use recent theory to develop better structures for their systems, and its subsequent use to implement the systems preserves those structures in the product.

A data abstraction language based on microprogramming

The paper describes the basic ideas in extending a machine-oriented microprogramming language into a system implementation language through data and control abstraction. The approach allows an extremely primitive base language to be bootstrapped to a higher level by a type definition mechanism where the operations of the types may be microprogrammed. Vertical migration is then possible by local modifications in operation definitions. On the other hand, a suitable type definition library would make it unnecessary for an ordinary user to know that all operations are ultimately based on microprogrammed definitions. This work is part of project Ukko which has designed a special microprogrammable computer for experimentation with user microprogramming.

Generation of Blisses

This presentation describes the simultaneous development of Bliss compilers for three machine architectures. A highly unusual combination of characteristics makes this development of general interest to the software development community: the development involved extensive sharing of code among the several compilers; involved bootstrapping and transportable programming using a machine-oriented systems implementation language; involved prototyping and subsequent evolutionary development; and involved developing software on, as well as for, three machine architectures. The unusual problems that arose are discussed and the methodologies for dealing with them are described. This experience should be of interest to others contemplating projects with similar characteristics. It should also be relevant to research in the area of software development environments as an example of the diverse needs to be met.

Axioms for user‐defined operators

AbstractSome programming languages allow the programmer to define operators. Algol‐68 allows user‐defined operator symbols with user‐defined priorities and user‐defined bodies; nevertheless the language rules insist on left‐to‐right evaluation of equal precedence operators. The new Department of Defense DoD language Ada allows the programmer to define new operators, but restricts them to language‐defined operator symbols with language‐defined priorities: in other words, only user‐defined bodies. The language rules concerning operators are therefore stronger, and imply properties of operators: ‘axioms’, which should apply even for use‐rdefined bodies. The paper discusses sensible constraints which should be accepted for user‐defined operatorsAn earlier version of this paper was presented at the IFIPWG2.4 (System Implementation Languages) meeting at Twente, June 1978. The author thanks members of WG2.4 for their comments. .

Systems implementation languages and IRONMAN

AbstractThe U.S. Department of Defense has recently issued a set of requirements, which it called IRONMAN, for the design of a programming language that it will use for embedded computer applications. To date four competing languages have been designed and, after considerable debate and scrutiny, these have been reduced to two. It is expected that the winning language will be selected during 1979.This report compares the IRONMAN requirements against the state‐of‐the‐art in systems implementation language design in an attempt to see the extent to which IRONMAN can be met from existing technology. Particular emphasis is given to the areas of large‐scale program structuring, parallel programming, exception handling and hardware interaction.Finally, Dijkstra's criticism of IRONMAN and the competing languages will be examined. It will be argued that he may be justified in doubting the viability of a language with such diverse features.

Programming languages for computer system simulation

This paper describes the programming language facil ities required to simulate computer systems. The systems considered include large multiprocessor, virtual memory computing systems, and networks of these systems. The models considered range from those which only roughly describe system resources to those which fully describe all user and system software. The complex models at the latter level require powerful language facilities which promote program modularity. These basic language facilities include list processing and programmer-definable data structures and data types. The relevant features of the following languages are considered: the general- purpose languages FORTRAN, ALGOL 60, PL/I, ALGOL 68, SIMULA 67, and PASCAL; the general-purpose simulation languages SIMSCRIPT II, GPSS V, GASP, and SPURT 70; the computer simulation languages CSS, OSSL, ECSS, ASPOL, PSML, and CREAM; and the system implementation languages CONCURRENT PASCAL, CLU, ALPHARD, MODULA, and EUCLID. Of these languages only SIMULA 67 and the system implementation languages provide the basic facilities. These features are also useful in the implementation of any large, complex model, particu larly when programming effort must be minimized.

How to call procedures, or second thoughts on Ackermann's function

AbstractVarious problems have been encountered in using Ackermann's function to measure the efficiency of procedure calls in System Implementation Languages. Although measurements have been made of some 60 systems, the ones presented here are included only when comparisons are possible. For conventional machine design, it is possible to draw some conclusions on desirable instruction set features. A surprising result from the analysis is that implementation quality is far more important than the overheads implied by language design.

System implementation in Algol 68‐R

AbstractWe illustrate the use of Algol 68 as a systems implementation language by reference to practical uses of the language. We argue that the code patch facility as implemented in Algol 68‐R is a good way of interfacing systems programs to their machine‐dependent environment, and does not violate the spirit of high‐level language programming.

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 on-line 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. This paper discusses four years of experience with PL-11, especially as this relates to the general topic of SILs on minicomputers.