Summary

In this thesis we have discussed an operating system project at the University of California, Berkeley, Computer Center. We have discussed many of the initial ideas and objectives of the project, the actual system constructed, and a number of reactions to that resulting system. The project was modest in size, involving about 30 man years. Except for a necessary item of peripheral hardware, the system was designed for a commercial computer, the Control Data 6400 with an Extended Core Store (ECS). We attempted to include a number of fundamental ideas in our design, including:

• specification of the entire system as an abstract machine,
• a capability based protection system,
• a mapped address space for each virtual computer (process),
• layered implementation including distributed system code,
• and uninterpreted input output devices.

It was intended that many of the services that must be supplied by a complete system would be provided by ``user'' level programs, whose special needs would be provided by system features. These features would be made available to ``ordinary'' user programs, as a matter of principle. The system made heavy use of ECS, a large core store with a fast block transfer rate (10 60 bits words per microsecond) to central memory. The state of each user process was stored in ECS, copied to central memory for execution and then copied back to ECS. The state of the system was maintained as the state of abstractly defined objects, whose representation was stored in ECS. Also, user programs accessed all real input output devices through the state of these abstractly defined objects. The system was designed in layers. The first layer (ECS system) provided 8 types of abstractly defined objects and about 100 actions to manipulate them. Subsequent layers provided a few (but very complicated) additional types of objects. (The entire second part of this thesis is devoted to a description of these various layers, and the abstract machines they define.) My major reaction to the resulting system was that it was disappointingly large, complex and slow. (Possibly this was due to naive expectations.) Many of our fundamental ideas served us well, particularly the concept of an abstract machine and capability based protection. However, mapped address space (on an unsuitable machine) and distributed system code were unsuccessful. Part 3 is devoted to an elaboration of my reactions to the system, along with a number of proposed improvements which would have mitigated some of the difficulties. In particular, I include a hardware proposal (a modification of ideas used on other projects) which would have greatly increased the efficiency of our capability based protection and abstract machine implementation.