Service Manuals, User Guides, Schematic Diagrams or docs for : xerox mesa 5.0_1979 The_Impact_of_Mesa_On_System_Design_1979

<< Back | Home

Most service manuals and schematics are PDF files, so You will need Adobre Acrobat Reader to view : Acrobat Download Some of the files are DjVu format. Readers and resources available here : DjVu Resources
For the compressed files, most common are zip and rar. Please, extract files with Your favorite compression software ( WinZip, WinRAR ... ) before viewing. If a document has multiple parts, You should download all, before extracting.
Good luck. Repair on Your own risk. Make sure You know what You are doing.



Image preview - the first page of the document



>> Download The_Impact_of_Mesa_On_System_Design_1979 documenatation <<

Text preview - extract from the document

                           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

◦ Jabse Service Manual Search 2024 ◦ Jabse Pravopis ◦ onTap.bg ◦ Other service manual resources online : Fixya ◦ eServiceinfo