Text preview for : The_Impact_of_Mesa_On_System_Design_1979.pdf part of xerox The Impact of Mesa On System Design 1979 xerox mesa 5.0_1979 The_Impact_of_Mesa_On_System_Design_1979.pdf
Back to : The_Impact_of_Mesa_On_Sys | Home
The Impact of Mesa on System Design
Hugh C. Lauer
Edwin H. Satterthwaite
Xerox Corporation
Palo Alto, California
Abstract
The Mesa programming language supports program modularity in ways that permit
subsystems to be developed separately but to be bound together with complete type
safety. Separate and explicit interface definitions provide an effective means of
communication, both between programs and between programmers. A configuration
language describes the organization of a system and controls the scopes of interfaces.
These facilities have had a profound impact on the way we design systems and organize
development projects. This paper reports our recent experience with Mesa, particularly
its use in the development of an operating system. It illustrates techniques for
designing interfaces, for using the interface language as a specification language, and for
organizing a system to achieve the practical benefits of progrmn modularity wjthout
sacrificing strict type-checking.
Mesa is a programming language designed for system implementation. It is used within the Xerox
Corporation both by research laboratories as a vehicle for experiments and by development
organizations for 'production' programming. Some of our initial experience with Mesa was
reported previously [Geschke et ai, 1977]. Since that time, the language has evolved in several
directions and has acquired a larger and more diverse community of users. That community has
accumulated a substantial amount of experience in using Mesa to design and implement large
systems, a number of which are now operational. It has beCOme increasingly clear that the value
of Mesa extends far beyond its enforcement of type-safety within individual programs. It has
profounuly affected the ways we think about system design, organize development projects, and
communicate our ideas about the systems we build.
This paper reports some of our recent experience with Mesa. It is based primarily upon the
development of one particular system-what we refer to as the Pilot operating system-tbr a small,
personal computer. We also draw upon the lessons learned from other systems. These represent a
non-trivial amount of programming; a survey of just the authors' immediate colleagues at the end
of 1978 uncovered several hundred thousand lines of stable, operational Mesa code. Pilot itself is
a 'second generation' client of Mesa. It is the first major system to take advantage of explicit
interface and configuration descriptions (discussed below) in its original design. rn addition, its
designers were ai>le to make careful assessments of earlier systems to discover both the benefits
i.md pitfalls of using Mesa. As a result, we were able to benefit from, as well as add to, the
accumulated 'institutional learning' about the practical problems of developing large systems in
Mesa.
The purpose of this paper is to communicate those lessons, which deserve more emphasis and
discussion than they have received to date in the literature. We concentrate upon the impact and
adequacy of the Mesa programming language and its illfluenceupon system design; a companion
paper [Lynch and Horsley, 1979J focuses upon organizational and marwgement issues. This paper
contains three main sections. First, the fm:ilities provided by Mesa for supporting the development
2 H. C. LAUER AND E. H. SATIERTHWAITE
and organization of modular programs are discussed. In the second section, we describe the role
played by the Mesa interface 'and configuration languages in system design, particularly from the
perspective of Pilot. The final section is a qualitative assessment of the adequacy of Mesa as a
system implementation language.
Context
Mesa is both a language and a system. The Mesa language features strict type-checking much like
that of PASCAL [Wirth, 1971] or EUCLID [Lmnpson et aI, 1977], with similar advantages and
disadvantages. In particular, the type-checking moves a substantial amount of debugging from
run-time to compile-time. Much has been written on this subject; our views and design decisions
have changed little since our earlier report [Geschke et aI, 1977]. The type system of Mesa
pervades all other aspects of the language and system. The latter consists of a compiler, a binder,
a source language debugger, and a number of other tools and utilities. The system has been
implemented on machines that can be microprogrammed at the register transfer level; thus we
have also been able to design and impicment a machine architecture specifically tailored to Mesa.
Mesa is an evolving language and system. The published version of the language manual [Mitchell
et al. 1978] differs from descriptions presented in earlier papers in a number of ways, most notably
in the explicit definition and control of interfaces. More recently, processes, monitors, and
synchronization have been added; these resemble the 'procedure-oriented model' of [Lauer and
Needham, 1978]. The compiler, instruction set, and microprogrammed interpreters have all
evolved to accommoda~e tllese changes.
Ine Pilot operating system upon which this report is based is programmed entirely in Mesa, as are
all of its clients. In addition to providing tlle usual set of operating system facilities, Pilot
implements all of the nm-time machinery needed to support tile execution of Mesa programs,
including itself. The clients are assumed to be friendly and cooperating, not hostile or malicious.
Since no debugging takes place on machines that are simultaneously supporting other users, no
attempt has been made to provide a strong protection mechanism; instead the goal has been to
minimize the likelihood of uncontrolled damage due to residual errors. Pilot was designed and
implemented by a core group oJ' six people, with important contributions by members of other
groups in specialized areas. By late 1978, the total system consisted of approximately twenty five
thousand lines of Mesa code.
Modularity in Mesa
Systems built in Mesa are collections of modules. The general structure of a Mesa module is
described in [Geschke et aI, 19771. Viewed as a piece of source text, a module resembles an
ALGOL procedure or SIMULA class declaration. Although the Mesa language enfbrces no particular
style of module usage, a de facto standard has evolved. An instance of a module typically manages
a collection of objects. Each object contains infonnation characterizing its own state. The module
instance provides a set of procedures to create, operate upon, and destroy the objects; it contains