Personal Distributed Computing: The Alto and Ethernet Software

2.2.Languages and environments

One of the distinctive features of the Alto as a programmer’s system is the wide variety of programming environments it supports: bcpl, Smalltalk, Mesa, and Lisp. Each of these has its own language, which gives the environment its name, and its own instruction set, imple­mented by its own microcode emulator; the bcpl instruction set is al­ways present, and there is a RAM with room for a thousand microinstructions, enough for one other emulator. Each also has its own compiler, loader, runtime system, debugger, and library of useful subroutine packages. The ensuing subsections describe these parts for each of the Alto environments.

Distinct environments communicate only by world-swap or through the file system. This isolation is not a good thing in itself, but it allows each system to stretch the resources of the machine in a differ­ent way, and thus to support effectively a particular programming style that would be impractical on such a small machine if all of the systems had to share a common instruction set and operating system.

2.2.1.BCPL

bcpl [40] is an implementation language quite similar to C (indeed, it is C’s immediate ancestor). bcpl has a fairly portable compiler which Jim Curry ported to the Data General Nova, and thence to the Alto. Curry also wrote a loader for compiled code. It can produce an executa­ble image or an overlay file that can be loaded and unloaded during execution; overlays are used in several large programs to make up for the limited address space. The Swat debugger, built by Jim Morris, is the other component of the bcpl programming environment; it un­derstands bcpl’s symbols, but is basically a machine-language debug­ger. The entire bcpl environment is very much like the C environment in Unix. Most Alto software was programmed in bcpl until 1977. By 1978 new programs were being written almost entirely in the other languages.

2.2.2.Mesa

Mesa [15] is an implementation language descended from Pascal. Its distinguishing features are:

• 
  Strong type-checking, which applies even across separate com­pilation units.
  
• 
  Modules, with the interface to a module defined separately from its implementation. Inter-module type-checking is based on the interface definitions; an implementation can be changed without affecting any clients [30].
  
• 
  Cheap facilities for concurrent programming, well integrated into the language [28].
  
• 
  A very efficient implementation, which uses an instruction set highly tuned to the characteristics of the client programs [20]. Compiled Mesa programs are typically half the size of similar C programs for the VAX, for example. The instructions are called byte-codes; many are a single byte long, and none are longer than three bytes. The byte-codes are interpreted by a micro­coded emulator.
  
• 
  A symbolic debugger well integrated with the source language and the type system, which allows breakpoints to be placed by pointing at the source code, and values to be printed in a form based on their type.
  

Mesa was begun in 1971 on a time-sharing computer by Jim Mit­chell, Chuck Geschke, and Ed Satterthwaite; ported to the Alto in 1975 with the assistance of Rich Johnsson and John Wick; and adopted by SDD in 1976 as the programming language for all SDD products. It continued to evolve there into a complete integrated programming en­vironment [49]. A separate path of evolution in CSL led to the Cedar system described below.

The main goal of the Mesa research and development was to sup­port the construction of large software systems and to execute them efficiently. This was accomplished very successfully: by 1982 there were several systems programmed in Mesa that contain more than a quarter of a million lines of code each, and many more that are 20 to 50 thousand lines long.

2.2.3.Smalltalk

The Smalltalk system is an integrated programming environment for the Alto, the first one to be built. It consists of a programming lan­guage, a debugger, an object-oriented virtual memory, an editor, screen management, and user interface facilities [22]. The latter are dis­cussed in section 5.

The Smalltalk language is based on objects and classes; each object has a class, which is a collection of procedures that operate on the object. A subclass inherits the procedures of an existing class, and gen­erally adds new ones. The class of an object acts as its type, which is determined at runtime; when a procedure is applied to an object, the name of the procedure is looked up in the object’s class to find the proper code to execute. Smalltalk source code is compiled into byte-codes similar to the ones used for Mesa, although much more powerful (and hence slower). The bytecodes are quite close to the source, so the compiler is small and fast; a typical procedure can be compiled and installed in a few seconds on an Alto, without disturbing the rest of the running system.

Objects are allocated and garbage-collected automatically. A class is itself an object, as are the source and compiled code for each proce­dure, and the stack frame for an executing procedure. So everything in the system can be accessed as an object and manipulated by Smalltalk programs within the system [19]. The entire system contains 100 to 200 classes, ranging from streams and collections to processes and files, rectangles and splines [16].

The dynamic typing, garbage collection, accessibility of every part of the system, and the ease with which a procedure can be added or changed without any loss of state, make Smalltalk similar to Lisp as a programming environment. The object-oriented programming style and the subclass structure, along with the careful design of the hier­archy of standard classes, give Smalltalk its unique character. The sys­tem is fairly easy to learn, and very easy to use for building prototypes Its limitations are relatively slow execution and (in the Alto implemen­tations) modest memory capacity; these factors have prevented pro­duction systems from being built in Smalltalk.

There have been three generations of the Smalltalk language and system: Smalltalk-72, Smalltalk-76, and Smalltalk-80; the description above refers to the latter two. The first two run on the Alto, the last on the Dorado and also on several VAX, 68000, and 80286 implementa­tions.

2.2.4.Lisp

Several researchers in CSL used PDP-10 Interlisp [54,55] for their pro­gramming in the 1970s. Interlisp became part of the Alto system through software that allows the Alto to be used as a very capable graphics terminal [45] that supports multiple fonts and windows, along with the standard Alto raster graphics primitives (see section 5). The resulting Interlisp-D system [52] was the first to integrate graphics into a Lisp system.

A complete Interlisp system was built for the Alto by Peter Deutsch and Willie-Sue Haugeland [9,10]. It uses many of the bcpl OS packages for operating system functions, and the Lisp runtime is also written in bcpl. Lisp programs are compiled into byte-codes much like those used for Mesa and Smalltalk; they fall about half-way between those in the amount of work done by a single instruction. As with Mesa, programs are about twice as compact as when compiled for a conventional instruction set. The system uses an encoded form for list cells, which allows a cell to be represented in 32 bits most of the time, even though addresses are 24 bits.

Alto Lisp worked, and was able to run most of PDP-10 Interlisp, but it was too slow to be useful, mainly because of insufficient mem­ory. It therefore did not play a role in the Alto system. The implemen­tation was moved to the Dorado, however, where after considerable tuning it has been very successful [7].

2.2.5.Cedar

With the advent of the Dorado in 1979, we saw an opportunity to im­prove substantially on all of our existing programming systems. After considerable reflection on the desirable properties of a programming environment for personal computing [11], CSL decided in 1979 to build a new environment, based on Mesa, to exploit the capabilities of the Dorado. The goals were significantly better tools for program develop­ment, and a collection of high-quality packages implementing the ma­jor abstractions needed to write applications.

Cedar added several things to the program development system: garbage-collected storage, dynamic types, complete program access to the representation of the running program, a version control system, and uniform access to local and remote files. It also had a large assort­ment of generally useful packages: an integrated editor for structured documents, a powerful graphics package, a relational database system, remote procedure calls, user-programmable interpretation of the key-board and mouse, and a screen manager based on icons and non-over­lapping windows [51, 53].

By early 1982 the Cedar system was usable; by mid-1983 it had grown to about 400,000 lines of code, ranging from the compiler and runtime support to an electronic mail system based on the Cedar editor and database system. It was possible to implement real time servers such as a voice data storage system and a transactional file system, using the full facilities of Cedar.

Cedar was quite successful in overcoming the major limitations of the Alto programming environment. It also succeeded in providing good implementations for a number of widely used high-level abstrac­tions. However, an additional goal was to equal Lisp and Smalltalk in supporting rapid program changes and late binding, and here it was less successful. In spite of this limitation, it probably represents the state of the art in programming environments for workstations in 1984.