Butler W. Lampson
Systems Research Center
Digital Equipment Corporation
Note: This web page was converted
automatically from a Word original. There may be problems with the formatting
and the pictures. To see the intended form, follow one of the links below.
Citation: B. Lampson. A History of Personal Workstations, ed. A. Goldberg, Addison-Wesley, 1988, pages 291-344
Links: Postscript, Acrobat, Web page, Word. The 1972 memo describing the Alto project is here.
Email: blampson@microsoft.com. This paper is at http://research.microsoft.com.
A substantial computing system based on the Alto [58] was developed at the Xerox Palo Alto Research Center between 1973 and 1978, and was considerably extended between 1978 and 1983. The hardware base for this system is simple and uniform, if somewhat unconventional. The software, which gives the system its visible form and knits together its many parts, is by contrast complex, variegated, even ramified. It is convenient to call the whole complex of hardware and software “the Alto system”. This paper describes the major software components of the Alto system. It also tries to explain why the system came out as it did, by tracing the ideas that influenced it, the way these ideas evolved into the concept of personal distributed computing, and the nature of the organization that built the Alto. A companion paper by Chuck Thacker [56] describes the hardware.
But a man’s reach should exceed his grasp, or what’s a heaven for? — Browning
The Alto system grew from a vision of the possibilities inherent in computing: that computers can be used as tools to help people think and communicate [39]. This vision began with Licklider’s dream of man-computer symbiosis [32]. When he became head of the Information Processing Techniques Office at ARPA, Licklider pursued the dream by funding the development of computer time-sharing. His successors, Ivan Sutherland, Robert Taylor, and Larry Roberts, continued this work throughout the 1960s and extended it to computer networks. Taylor went on to manage the laboratory in which most of the Alto system was built, and people who worked on these ARPA projects formed its core. Their collective experience of time-sharing and networks became a major influence on the Alto design.
Another important influence, also funded by ARPA, was Doug Engelbart. He built a revolutionary system called NLS, a prototype of the electronic office. In NLS all the written material handled by a group of people is held in the computer and instantly accessible on a display that looks something like an ordinary sheet of paper. He demonstrated this system at the 1968 Fall Joint Computer Conference in San Francisco [12,13]. NLS was too expensive to be practical then, but it made a profound impression on many of the people who later developed the Alto.
Yet another ARPA project that had a strong influence on the Alto was Alan Kay’s Flex machine, also called the Reactive Engine [21]. Kay was pursuing a different path to Licklider’s man-computer symbiosis: the computer’s ability to simulate or model any system, any possible world, whose behavior can be precisely defined. And he wanted his machine to be small, cheap, and easy for nonprofessionals to use. Like Engelbart, he attached great importance to a high-quality, rapidly changing display. He later coined the name “Dynabook” for the tool he envisioned, to capture its dynamic quality, its ubiquity, and its comfortable fit with people [22].
The needs of the Xerox Corporation also influenced the Alto, since Xerox provided the money that paid for it. In 1970 Xerox started a research center in Palo Alto called PARC to develop the “architecture of information” and establish the technical foundation for electronic office systems that could become products in the 1980s. It seemed likely that copiers would no longer be a high-growth business by that time, and that electronics would begin to have a major effect on office systems, the firm’s major business. Xerox was a large and prosperous company with a strong commitment to basic research and a clear need for new technology in this area. To the computer people at PARC, this looked like a favorable environment in which to take the next step toward making computers into effective tools for thinking.
The electronic office and the Dynabook, then, were the two threads that led to the Alto system. The idea of the electronic office is to do all the work of an office using electronic media:
· capturing information,
· viewing it,
· storing and retrieving it,
· communicating it to others, and
· processing it.
The idea of the Dynabook is to make the computer a personal and dynamic medium for handling information, which can model the world and make the model visible.
Of course the Alto system is not an electronic office, or a Dynabook; these were ideals to draw us on, not milestones to be achieved (or millstones either). In the course of developing the Alto we evolved from these ideals to a new style of computing, which is the preferred style in the 1980s just as time-sharing was the preferred style of the 1970s; witness the conference for which this paper was prepared. For this style there is no generally accepted name, but we shall call it “personal distributed computing”. Why these words?
The Alto system is personal because it is under the control of a person and serves his needs. Its performance is predictable. It is reliable and available. It is not too hard to use.
And it is fast enough. In 1975 it was hard for people to believe that an entire computer is required to meet the needs of one person. The prevailing attitude was that machines are fast and people are slow; hence the merits of time-sharing, which allows one fast machine to serve many of the slow people. And indeed time-sharing, with response times measured in seconds, is an advance over a system that responds in hours. But this relationship holds only when the people are required to play on the machine’s terms, seeing information presented slowly and inconveniently, with only the clumsiest control over its form or content. When the machine is required to play the game on the human’s terms, presenting a pageful of attractively (or even legibly) formatted text, graphs, or pictures in the fraction of a second in which the human can pick out a significant pattern, it is the other way around: People are fast, and machines are slow. Indeed, it is beyond the current state of the art for a machine to keep up with a person. But the Alto system is a step in this direction.
So a personal system should present and accept information in a form convenient for a person. People are accustomed to dealing with ink on paper; the computer should simulate this as well as possible. It should also produce and accept voice and other sounds. Of these requirements, we judged most important the ability for the machine to present images, and for its user to point at places in the image. The Alto can do this quite well for a single 8.5" x 11" sheet of paper with black ink; it puts no restrictions on the form of the images. It cannot read images, nor can it handle sound; other people’s experience suggests that these abilities, while valuable, are much less important.
The Alto system is distributed because everything in the real world is distributed, unless it is quite small. Also, it is implicit in our goals that the computer is quintessentially a communication device. If it is also to be personal, then it must be part of a distributed system, exchanging information with other personal computers. Finally, many things need to be shared, not just information but expensive physical objects like printers and tape drives.
Finally, the Alto system is a computing system, adaptable by programming to a wide and unpredictable variety of tasks. It is big and fast enough that fitting the programs into the machine is not too hard (though the Alto’s address space and memory size limitations were its most serious deficiency). And programming is possible at every level from the microcode to the user of an application. It is interesting, though, that user programming plays a much smaller role in the Alto system than in Unix [23] or EMACS [46]. Users interact with the system, nearly to the exclusion of programming it. In retrospect it seems that we adopted this style because interacting with the Alto was so new and enthralling, and that we went too far in excluding systematic programming facilities like the Unix shell or M-Lisp in EMACS. The same mistake was made in early time-sharing systems such as CTSS [8] and the SDS 940 [26], whose builders were enthralled by a cruder kind of interaction, so we should have known better.
Systems resemble the organizations that produce them. — Conway
The Alto system was affected not only by the ideas its builders had about what kind of system to build, but also by their ideas about how to do computer systems research. In particular, we thought that it is important to predict the evolution of hardware technology, and start working with a new kind of system five to ten years before it becomes feasible as a commercial product. If the Alto had been an article of commerce in 1974, it would have cost $40,000 and would have had few buyers. In 1984 a personal computer with four times the memory and disk storage, and a display half the size, could be bought for about $3500. But there is still very little software for that computer that truly exploits the potential of personal distributed computing, and much of what does exist is derived from the Alto system. So we built the most capable system we could afford within our generous research budget, confident that it could be sold at an affordable price before we could figure out what to do with it. This policy was continued in the late 1970s, when we built the Dorado, a machine with about ten times the computing power of an Alto. Affordable Dorados are not yet avail-able, but they surely will be by the late 1980s. Our insistence on workmg with tomorrow’s hardware accounts for many of the differences between the Alto system and the early personal computers that were coming into existence at the same time.
Another important idea was that effective computer system design is much more likely if the designers use their own systems. This rule imposes some constraints on what can be built. For instance, we had little success with database research, because it was hard to find significant applications for databases in our laboratory. The System R project [17] shows that excellent work can be done by ignoring this rule, but we followed it fairly religiously.
A third principle was that there should not be a grand plan for the system. For the most part, the various parts of the Alto system were developed independently, albeit by people who worked together every day. There is no uniform design of user interfaces or of system-wide data abstractions such as structured documents or images. Most programs take over the whole machine, leaving no room for doing anything else at the same time, or indeed for communicating with any other program except through the file system. Several different language environments are available, and programs written in one language cannot call programs in another. This lack of integration is the result of two considerations. First, many of the Alto’s capabilities were new, and we felt that unfettered experimentation was the best way to explore their uses. Second, the Alto has strictly limited memory and address space. Many applications are hard enough to squeeze into the whole machine and could not have been written if they had to share the hardware resources. Nor is swapping a solution to the shortage of memory: The Alto’s disk is slow, and even fast swapping is inconsistent with the goal of fast and highly predictable interaction between the user and the machine.
There was some effort to plan the development of the Alto system sufficiently to ensure that the basic facilities needed for daily work would be available. Also, there was a library of packages for performing basic functions like command line parsing. Documentation for the various programs and subroutine packages was maintained in a uniform way and collected into a manual of several hundred pages. But the main force for consistency in the Alto system was the informal interaction of its builders.
The outstanding exception to these observations is the Smalltalk system, which was built by a tightly knit group that spent a lot of effort developing a consistent style, both for programming and for the user interface. Smalltalk also has a software-implemented virtual memory scheme that considerably relaxes the storage limitations of the Alto. The result is a far more coherent and well-integrated world than can be found in the rest of the Alto system, to the point that several of the Alto’s successors modeled their user interfaces on Smalltalk. The price paid for this success was that many Smalltalk applications are too slow for daily use. Most Smalltalk users wrote their papers and read their mail using other Alto software.
There was much greater consistency and integration of components in later systems that evolved from the Alto, such as Star and Cedar. This was possible because their designers had a lot of experience to draw on and 4 to 16 times as much main storage in which to keep programs and data.
The Alto system was built by two groups at PARC: the Computer Science Laboratory (CSL), run by Robert Taylor and Jerome Elkind, and the Learning Research Group (LRG), run by Alan Kay. LRC built Smalltalk, and CSL built the hardware and the rest of the system, often in collaboration with individuals from the other computer-related laboratory at PARC, the Systems Science Laboratory. George Pake, as manager first of PARC and then of all Xerox research, left the researchers free to pursue their ideas without interference from the rest of Xerox.
The Star system, a Xerox product based on the Alto [43], was built by the System Development Division (SDD), run by David Liddle. The Dorado, a second-generation personal computer [27] and Cedar, a second-generation research system based on the Alto [53], were built in CSL. Table 1 is a chronology of these systems.
A number of ideas that might have been incorporated into the Alto system did not find a place there. In some cases we made deliberate decisions not to pursue them, usually because we couldn’t see how to implement them on the Alto within an interactive application. Classical computer graphics, with viewports, transformations, clipping, 3-D projection and display lists, falls in this category; one implementation of a computer graphics package was done, but it didn’t get used because it took up too much of the machine. High-quality typesetting (as in TeX [24]) is another; doing this interactively is still an unsolved problem. Linking together a large collection of documents so that the cross-references can be quickly and easily followed, as Engelbart did in NLS [13] is a third. Most of these ideas were incorporated into Cedar.
We also did very little with tightly linked distributed computing. The 150 Altos at PARC could have been used as a multi-processor, with several of them working on parts of the same problem. But except for the Worm programs described in the third section, this was never tried. And, as we have already seen, the Alto system gave little attention to high-level programming by users.
Other things were tried, but without much success. We built two file servers that supported transactions, one low-level database system, and several applications that used databases. In spite of this work, by 1984 databases still did not play an important role in the Alto system or its successors. This appears to be because the data in our applications is not sufficiently well-structured to exploit the capabilities of a database system. Most Unix users apparently have had similar experiences.
We also tried to apply ideas from Alto office systems, with work on natural language understanding and on expert systems. But ten years of work did not yield systems based on these ideas that were useful enough to make up for their large size and slow speed. A full-scale Lisp system was built for the Alto, but the machine proved too small for it in spite of much effort; this system was later successful on larger machines.
1973 1974
1975 1976 1977
1978 1979 1980
1981 1982
HARDWARE
Alto —- Alto 2 Dolphin ----------
Dorado ------------------------- Dicentra ---
Wildflower Dandelion ----
mouse mouse
Ethernet Ears ----
Dover --------
8044 -------
Orbit ----
Puffin ---
OPERATING SYSTEMS
Alto OS ---
Pilot---------------------------------
Cedar exec --
Scavenger
Alto exec
LANGUAGES
BCPL – Swat Mesa
------------------------------------
Cedar -----—-
Mesa
debugger ------------------------------
Copilot ----------------------------—-
Smalltalk 72 ---
Smalltalk 76 -------- Smalltalk
80 ------
Alto Lisp ---------- Interlisp D --------
COMMUNICATIONS
Pup
----- worm RPC ------------------
Chat Grapevine ----------
FTP
SERVERS
Ears ------ Press
-------- Spruce Interpress
Juniper
------------------------------
Alpine --------------
WFS IFS -----
APPLICATIONS
Gypsy
Officetalk Star
----------------------------
Smalltalk windows
Tajo ---------------
Viewers
Bravo
-------------- Laurel --- BravoX
-------- Tioga ----------
Sil Markup Sil
Fred ---- AIS
Draw
Table 1: Systems and chronology
One important idea that would have been a natural application for the Alto was simply overlooked: spreadsheets. Probably this happened because except for the annual budget planning and keeping track of purchase orders, there were no applications for spreadsheets in the research laboratory.
The Alto system software was begun in the middle of 1973. In October 1976 the Alto User’s Handbook was published [25]. It describes a system that includes an operating system, a display-oriented editor, three illustrators, high-quality printing facilities, and shared file storage and electronic mail provided by local network communication with a timesharing machine. There were also two programming languages and their associated environments. This was a complete personal distributed computing system; it met nearly all of the computing and information-handling needs of CSL and LRG.
The rest of this paper tells the story of the Alto system from the bottom up, except for the hardware, which is described elsewhere [56]. The second section covers programming: operating systems, programming languages, and environments. The third section presents the basic communication facilities: Internet protocols, remote procedure calls, file transfer, and remote terminals. The fourth section discusses the servers that provide shared resources: long-term storage, printing, naming and mail transport.
The last two sections deal with the parts of the system that interact with users, which after all is the purpose of the whole enterprise. The fifth section considers the user interfaces: how the screen is organized into windows, how images are made, and how user input is handled. The sixth section describes the major applications, programs the user invokes to do some job with results that are useful outside the computer system. In the Alto system these are text editors, illustrators, electronic mail, and computer-aided design programs.
The conclusion reflects on the future of personal distributed computing and the nature of computer systems research.
Throughout I describe the Alto system in some detail, especially the parts of it that have not been described elsewhere. I also sketch its evolution into the Dorado system and the Xerox 8000 products (usually called Star). The “Dorado system” actually runs on three machines: Dolphin, Dorado, and Dandelion. These have different microengines, but the same virtual memory structure, and all the major programming environments run on all three systems. They differ in performance and availability: the Dolphin, with about twice the power of the Alto and ten times the memory, first ran in 1978; the Dorado, ten times an Alto, in 1979; the Dandelion, three times an Alto, in 1980. Star runs on the Dandelion and was announced in 1981. A fourth member of the family, the Dicentra, was designed as a server and runs only the Mesa environment.
Readers may be surprised that so much of this paper deals with software that has little or nothing to do with the display, since “screen flash” is the most obvious and most immediately attractive property of the Alto system. They should remember that the Alto system put equal emphasis on personal and on distributed computing, on interacting with the computer and on communicating through it. It also seems important to explain the programming environment that made it possible to develop the large quantity of software in the Alto system.
The Alto system is programmed in a variety of languages: BCPL, Mesa, and Smalltalk (see the section entitled Languages and Environments). Each language has its own instruction set and its own operating system. The entire system has in common only the file system format on the disk and the network protocols. These were established by the BCPL operating system and did not change after 1976; they constitute the interface between the various programming environments.
The first Alto operating system [29], usually called the OS, is derived from Stoy and Strachey’s 056 [47]. It provides a disk file and directory system, a keyboard handler, a teletype simulator for the screen, a standard stream abstraction for input-output, a program loader, and a free storage allocator. There is no provision for multiple processes, virtual memory, or protection, although the first two were provided (several times, in fact) by software or microcode packages. The OS is written entirely in BCPL [40]. It was designed by Butler Lampson, and implemented by him, Gene McDaniel, Bob Sproull, and David Boggs.
The distinctive features of the Alto OS are:
· its open design, which allows any part of the system to be replaced by client program;
· the world-swap facility, which exchanges control between two programs, each of which uses essentially all of the machine; and
· the file system, which can run the disk at full speed and uses distributed redundancy to obtain high reliability.
The OS is organized as a set of standard packages, one providing each of the functions mentioned (except for the stream abstraction1 which is entirely a matter of programming convention). When it is initialized, all the packages are present and can be called by any program that is loaded. However, there is a junta procedure that can be used to remove any number of the pre-loaded packages and recover the space they occupy. Thus a program can take over nearly the whole machine. BCPL programs can include any subset of the standard packages to replace the ones removed by the junta. Alternatively, they can provide their own implementation of a function that has been removed by a junta, or do without it altogether. Thus the system is entirely open, offering services to its client programs but preempting none of the machine’s resources. Other packages not normally loaded as part of the system, but available to be included in any user program, provide non-preemptive concurrent processes, Internet datagrams and byte streams, program overlays, and other facilities that might have been part of the standard system.
At the base of the OS is a world-swap function that saves the entire state of the machine on a disk file and restores it from another file; this allows an arbitrary program to take control of the machine. The new program communicates with the old one only through the file system and a few bytes of state that are saved in memory across the world swap. The world-swap takes about two seconds; it is used for bootstrapping, checkpointing, debugging (to switch between the program and the debugger), and switching back and forth between two major activities of a program.
The file system represents a file as a sequence of disk blocks linked by forward and backward pointers. By careful integration with the disk controller, it is able to transfer consecutive file blocks that are contiguous on the disk at the full disk speed of 1 MBit/second, while leaving time for nontrivial client computing; this performance allows world swapping, program overlaying, and other sequential file transfers to be fast. In addition, each disk block contains the file identifier and block number in a label field of its header; this information is checked whenever the block is read or written. As a result, the disk addresses of file blocks can be treated as hints by the system, rather than being critical to its correct functioning and to the integrity of other files. If a disk address is wrong, the label check will detect the error, and various recovery mechanisms can be invoked. A Scavenger program, written by Jim Morris, takes about a minute to check or restore the consistency of an Alto file system; it can be routinely run by nonprofessional users. As a result of this conservative design, the file system has proved to be very reliable; loss of any information other than bits physically damaged on the disk is essentially unheard of. This reliability is achieved in spite of the fact that many programs besides the standard operating system have access to the disk.
The file system also runs on the 80 and 300 MByte disks that are interfaced to some Altos, and in this form is the basis of a successful file server (see the section entitled Storage).
The Alto has a conventional hierarchical directory system that allows multiple versions of each file1 with provisions for keeping a prespecified number of versions. The subdirectory and version facilities were added late, however, and did not enjoy widespread use. A directory is stored as an ordinary file that is processed by a variety of programs in addition to the file system.
A program called the Executive processes command lines and invokes other programs; it is much like the Unix Shell, but with far more primitive facilities for programming at the command level. From the point of view of the OS it is just another program, the one normally invoked when the machine is booted. From the point of view of a user it is the visible form of the OS.
Some of the design choices of the Alto OS would not be made in an operating system for a 1985 workstation; its much greater computing power and especially memory capacity make them unattractive. Separate address spaces simplify program development and concurrent execution of separate applications; virtual memory simplifies programming; a clean virtual machine makes it easier to port client programs to a new machine. But these comforts have a significant cost in machine resources: memory and response time. The open and unprotected character of the Alto OS were essential to the success of many Alto applications, both interactive programs like editors and illustrators, and real-time programs like the file, print, and gateway servers.
Distinct operating systems evolved for other programming environments. The Alto Lisp and Smalltalk operating systems were built using many of the Alto OS packages. Over time, these packages were replaced by new code native to the Lisp and Smalltalk environments. Mesa had its own operating system on the Alto from the start, but it was modeled closely on the OS.
For the Xerox 8000 products, the Alto OS was replaced by a considerably bigger system called Pilot, which supports virtual memory, multiple processes, and a more elaborate file system [38]. Pilot was also used in the Cedar system, but was eventually supplanted by the Cedar nucleus, a much simpler system quite similar in spirit to the Alto OS. Cedar also has CFS, the Cedar File System [41], which provides a network-wide file system to Cedar programs by caching files from a server on the workstation. In CFS modified files are written back only by explicit request. This arrangement supports about 20 Dorados from a single Alto-based file server, using about 30 MBytes of local disk on each Dorado for the cache. Almost any file server will do, since it need only support full file transfers.
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, implemented by its own microcode emulator; the BCPL instruction set is always 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 different 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.
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 executable 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 BCFL programming environment; it understands BCPL’s symbols, but is basically a machine-language debugger. The entire BCFL 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.
Mesa [15] is an implementation language descended from Pascal. Its distinguishing features are:
· Strong type-checking, which applies even across separate compilation units.
· Modules, with the interface to a module defined separately from its implementation. Intermodule 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 microcoded 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 Mitchell, 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 environment [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 support 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.
The Smalltalk system is an integrated programming environment for the Alto, the first one to be built. It consists of a programming language, a debugger, an object-oriented virtual memory, an editor, screen management, and user interface facilities [22]. The latter are discussed in the fifth section.
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 generally 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 procedure, 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 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 hierarchy of standard classes, give Smalltalk its unique character. The system is fairly easy to learn, and very easy to use for building prototypes Its limitations are relatively slow execution and (in the Alto implementations) modest memory capacity; these factors have prevented production 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 implementations.
Several researchers in CSL used PDP-10 Interlisp [54,55] for their programming 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 the fifth section). 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 memory. It therefore did not play a role in the Alto system. The implementation was moved to the Dorado, however, where after considerable tuning it has been very successful [7].
With the advent of the Dorado in 1979, we saw an opportunity to improve 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 development, and a collection of high-quality packages implementing the major 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 assortment 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-overlapping windows [51,53].
By early 1982 the Cedar system was usable; by mid-1984 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 abstractions. 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.