F.J. Corbató

Genesis

The beginnings of the CTSS were when a Professor McCarthy, submitted a memo to the director of the MIT Computation Centre, Philip Morse, outlining the “time-sharing” principles. Philip Morse then encouraged Fernando Corbató and his team at M.I.T. to develop the CTSS. The first demonstration of the CTSS system was on the IBM 709 was according to Corbató “crude and incomplete” (see http://www.cnn.com/TECH/computing/9906/29/1961.idg/index.html)

Contemporaries

As well as the development of the CTSS there were some other interesting developments taking place at the same time, one of these was a machine called the Atlas, which was developed at a similar time to the CTSS. The development process of the Atlas brought about such techniques as virtual storage, paging as well as multiprogramming. The Atlas was officially inaugurated on the 7 December 1962.

Basic outline of system

The “mature” CTSS system was based on a modified IBM 7094 (provided by ARPA)

The original specifications of the IBM 7094 were

• 32K 36-bit words of memory.
• Its data channels could access memory and run simple channel programs to do I/O once started by the CPU.
• The channels could cause a CPU interrupt when the I/O finished.

Some of the modifications were

• A second 32K core memory bank was added.
• Several instructions were added to the processor.
• A memory boundary register was added to the processor.
• A hardware timer to interrupt user programs

The modifications to the 7094 meant that the computer the Professor Corbató was working with was now able to operate in two modes. Core bank A held the CTSS supervisor, and the B Core was used for user programs. The memory boundary register was used to limit the user job’s access to the B Core.

It was this ability to operate in two modes that lead to the “Compatible” portion of the systems title. The two modes enabled a system named the “Fortran Monitor System” to be run as a background user program in the B Core. The FMS had controlled first the 7090 and then the 7094, which were operated in batch mode. The ability of the CTSS to run FMS on the B Core meant that some degree of compatibility could be achieved and also eased the transition from the batch processing to time-sharing. (See http://www.multicians.org/thvv/7094.html)

Features of Interest

An interesting feature that was used in the CTSS system was an algorithm called the “onion skin”. If a small job followed a large job, the algorithm would leave parts of the larger job’s core image in memory. The algorithm could then relatively quickly reassemble the images after the smaller job had executed if needed.

The CTSS also provided a remote access facility from 1963 onwards. This made it possible for those with the correct equipment to connect to the CTSS by using a modem to connect using a specialised telecommunications computer, the IBM 7750. (See http://www.multicians.org/thvv/terminals.html)

Influence on subsequent OS

The CTSS had an influence on many other systems, which came after it. This was due in part to some of the fundamental concepts which had been introduced such as time-sharing. Some of the hardware modifications, which were introduced to enable time-sharing such as having a hardware timer to interrupt user programs, are still in use today. However the operating system which was to be influenced most by CTSS was the Multics system.

Genesis

The Multics system was a product of Project MAC. The Advanced Research Projects Agency of the U.S. Department of Defence funded the project. In a paper authored by Professor Corbató, J.H. Saltzer and C.T. Clingen we find that while the CTSS was being finished planning for a more fully featured system began, the goal was “the development of a new computer system specifically organised as a prototype of a computer utility.” (See http://www.multicians.org/f7y.html)

Professor Corbató wrote another report about the management of the project in which he highlighted some of the major design goals that the project had.

• Convenient remote terminal use.
• Continuous operation (i.e., without shutdown) analogous to power and telephone companies.
• A wide range of configuration capacity which could be dynamically varied without system or user program reorganisation.
• An internal file system with apparent reliability high enough for users to entrust their only copies of programs and data to it.
• The ability of users to share selectively information among themselves.
• The ability to store and create hierarchical structures of information for purposes of system administration and decentralisation of user activities.
• The ability to support a wide range of applications ranging from heavy numerical production calculations to inter active time-sharing users without inordinate inefficiency.
• The ability to allow a multiplicity of programming environments and human interfaces within the same system.
• The ability to evolve the system with changes in technology and in user aspirations.

(See Research Directions in Software Technology edited by P. Wegner, MIT Press, 1979 orhttp://www.multicians.org/managerial.html)

Influences

The development of Multics system began in earnest in 1964. As a collaboration between M.I.T., Bell labs and G.E. We can see how these various parties brought their own experience, ideas and goals. One of the major influences on Multics development was of course the experience gained by Professor Corbató’s team in developing CTSS.

Bell Labs had their own software development experiences, which they brought into the project, for example they too were mainly operating IBM 7090’s and 7094’s as were the CTSS team. However Bell Labs were mostly running their computers in batch mode. Bell Labs had also developed an in house operating system called BESYS, and were involved in several other software projects “notably BLODI (essentially, early dataflow architecture) and Snobol (string processing).” (See http://cm.bell-labs.com/cm/cs/who/dmr/mdmpipe.html)

G.E. provided the hardware for the Multics system. Initially the basic system chosen was the newly marketed GE 635.This computer was similar to the IBM 7094’s which Project MAC and Bell-Labs already had experience with, both machines had the same 36-bit word, accumulator, quotient register, index registers. The advantages of this computer were the support for multiple memory modules and multiple processors. Several modifications had to be made though to the basic model to accommodate some of the developments, which were proposed by the software developers. (See http://www.multicians.org/managerial.html)

How it was developed

The initial development was co-ordinated by two groups, a group called the Trinity, consisting of Robert M. Fano (M.I.T.), Edward E. David (B.T.L.) and C. Walker Dix (G.E.) made major policy decisions. However the actual management of the project was done by a group called the Triumvirate which consisted of Fernando J. Carbotó (M.I.T.), Peter G. Neumann (B.T.L.) and A. L. Dean (G.E.). The Triumvirate also had Jerome H. Saltzer and Edward L. Glaser as consultants on the project.

One of the revolutionary concepts introduced by the Multics development was the decision to implement the system in a high level language. The language chosen was PL/1 (Programming Language 1). Professor Corbató stated in his report “A Managerial View of the Multics System Development” that PL/1 was chosen “partly because of the richness of its constructs and partly because of the enthusiasm of those planning to implement the compiler” (see http://www.multicians.org/managerial.html), however there were problems to be overcome.

Due to the significant changes in hardware (The GE 635 became the GE 645) which were needed to implement some of the advanced features which Multics would incorporate there were no assemblers or compilers for the machine available. Problems were found when trying to modify an existing assembler from the related GE 635. An assembler was eventually built from scratch, however implementing PL/1 was a much tougher problem. The contract for providing a compiler was outsourced to another company but they failed to deliver a workable compiler after over a year (This can be attributed to the proposed vendor eventually realising that techniques used in constructing FORTRAN compilers do not extrapolate well when creating a PL/1 compiler). To remedy this a roughly implemented version of a PL/1 compiler (really a sub-set of the language) was implemented by the Multics team on which to begin implementing their system.

The time between beginning the project and obtaining a usable compiler was put to use in developing a document called the Multics System Programmers’ Manual (MSPM). This document was the eventually occupied around 3000 pages and constituted the “primary design document for the system. Most of the MSPM was written between 1965 and 1969.” (See http://www.multicians.org/devdoc.html)

Basic outline of system

The Multics system was designed to be used by multiple users and provide a wide array of services to the users of the machine.

A typical Multics system (in its development years) would consist of

• A GE 645 computer with two processors.
• Two Generalised Input/Output Controllers.
• Multiple memory modules.
• Storage Devices.

Some of the hardware modifications needed to implement the Multics system on GE machines were

• Change to processor architecture to enable suitable addressing of segmented memory to occur.
• Changes to the processor to enable the supervisor problem to handle paging of the memory.
• An interrupt clock and a non-repeating calendar clock were added to support some of the supervisor functions.
• A special purpose input/output controller.

Innovative Features

Some of the innovative features developed by the Professor Corbató’s team included

• Segmented memory.
• Virtual memory.
• Shared memory multiprocessor.
• On-line reconfiguration.

Technical Details

At the time Multics was implemented sharing information between users was primarily achieved through use of the input and output of files kept in secondary storage. Multics however achieves information sharing by using memory segmentation. “Information is stored in segments each of which is potentially sharable and carries its own independent attributes of size and access privilege”. (See Communications of the ACM, May 1972, Volume 15, Number 5, pp. 308-318.) To implement this system in Multics the computer is able to directly address any information held on the computer. The file system is integrated with the segmented memory. This means that apart from backup purposes it is not necessary to duplicate data on the computer as any program which need to access data is able to directly access that data.

One way in which Multics takes advantage of this is by supporting dynamic linking. Multics does not need to use a loader, duplication of routines or procedures in Multics is not necessary. When a user is running a compiled procedure and that procedure refers to another external procedure a “linkage fault” occurs. The system fault handler searches for the external procedure and when it is found it is dynamically linked to the running program. (See http://www.multicians.org/features.html for an example of this.)

The Multics system uses virtual memory, this is a technique, which is reasonably common today but at the time had only been seen in operation a few years earlier in 1962. Multics implements a “classical demand-paged virtual memory management system.”(See ftp://ftp.stratus.com/pub/vos/multics/pg/mvm.html). This is similar to the manner initially implemented in the Atlas system. The Addresses generated by the CPU are translated from a virtual address to an actual address. Access to the virtual memory is provided transparently using a hierarchical three-level scheme, using main storage, paging device, and disk.

Multics also developed a system of “rings” which expands beyond the usual superuser/user scheme most systems operate. Multics implements around 8 separate privilege levels. Rings are numbered 0 – 7. Ring 0 contains the supervisor program. Ring 1 contains extensions to the supervisor program. Vendor supplied programs are stored in Ring 2, user supplied programs are stored in Ring 3. Typical user programs are stored in Ring 4 and less privileged programs in Ring 5. Rings 6 and 7 are not able to directly access most system functions but have to call user supplied programs in other rings to accomplish useful work.

On-line reconfiguration is an interesting feature implemented in the Multics system, which was at the time. This feature enables the Multics system to reconfigure itself while still running. During development of the Multics system it was common for Professor Corbató’s team to reconfigure the computer to run as two separate computers, one to enable continued use of the system to it’s users and the second system for the developers to use to update the system. The system is able to have memory CPU’s and I/O handlers added to it while the system is running.

Multics offers a concept to the user called environment shaping. The system provides a project administrator the facility to define the initial environment to which the members of the project are presented. This is achieved by being able to specify an initial procedure for the system to implement when the specified user/s log on. While this may sound a fairly simple action, it opens up to the administrators the potential to implement and evolve a project environment entirely on their own. These subsystems may bear no actual resemblance to the procedural based Multics environment. Professor Corbató mentions a few of these sub-systems in analysing the effectiveness of the first seven years of the Multics system. The subsystems are

• The Dartmouth Basic [9] compiler executes in a closed subsystem implemented by an M.I.T. student group for use by undergraduate students. The compiler, its object code, and all support routines execute in a simulation of the native environment provided at Dartmouth. The users of this subsystem need little, if any, knowledge of Multics and are able to behave as if logged into the Dartmouth system proper.
• Other examples of controlled environment subsystems include one to permit many programs which normally run under the GCOS operating system to also run unmodified in Multics.
• Finally, an APL subsystem allows the user to behave for the most part as if he were logged into an APL machine. The significance of these subsystems is that their implementers did not need to interact with the system administrator or to modify already existing Multics capabilities.

The administrative facilities permit each such subsystem to be offered by its supporters as a private service with its own group of users, each effectively having its own private computer system. (See http://www.multicians.org/f7y.html).

Critical Evaluation