A single board on the MBus, containing at least the following hardware:

One may note that the hardware needed to support the Workstation IOP is sufficient to execute a high-level or modified high-level programming environment. A HLL approach would allow nearly immediate availability of a vehicle for prototyping an IOP. In particular, we could run a Unix-like software system without "user" processes. This system would provide a development environment at first, with, for example, low level device access and network access already implemented. Unix may require the addition of a memory management unit (MMU) to the IOP board. Or, we could restrict use to a Unix subset which provides the necessary functionality and does not required virtual memory support; the MMU would not be needed. Preliminary discussions with Unix wizards verified the feasibility of this approach.

At first, this may seem like a heavyweight solution to the IOP question, but further reflection and awarness of the resources available for this project make it attractive and sensible. As noted, we are already providing the hardware which can run a Unix-like environment The additional memory is cheap and we don't need much. Addition of an LSI chip MMU is really the only issue. If we adopt this course of action, we uncouple the software effort needed for the service system from the actual implementation of the IOP. We could begin software work as soon as possible on the CSL VAX or by purchasing a workstation from Sun Microsystems which provides the same hardware capability and operating system as the IOP will eventually have. There are people in CSL who have been thinking about this course of action and who are capable and willing to work in such an environment.

Within Unix, there is a large body of software drivers and utilities which we cannot afford to duplicate. We have ample evidence from the experience gained by the PARC Systems Concepts Lab that re-implementing low level functionality is frustrating and a waste of time. PARC/SCL is currently replacing several person-years of such development time on their Sun based Smalltalk system; they are porting Smalltalk to run directly on top of Sun Unix. Their efforts, and other work already underway for the Unix environment, such as the implementation of XNS protocols, may be used for the IOP.

With appropriate planning, all development can be directly ported to the IOP when it is ready. This plan provides a clean interface between CSL and ED, in that CSL would be responsible for software development and ED would be responsible for hardware development, with the two organizations using whatever liason and cooperation is needed to make this work.

Other advantages of working in a high-level environment include quick response to problems encountered during development, simulation of the interface between the MBus based systems and the IOP without the need for IOP hardware, and concentration of our efforts on the custom software we need for IO, booting, and diagnostics without having to first implement a system to support that software. Further, a Unix co-processor for a workstation could prove a valuable asset in future. In particular, the "C" Workstation might profit from having a Unix compatibility mode. We may make that happen and still have services performed for the Workstation proper.

In this scheme, the IOP is self-contained and does not depend on remote environments like Cedar or XDE to operate. Of course, remote debugging may be implemented, probably using an RPC protocol, to allow workstation tools to be built for remote access to the workstation via the IOP.

Finally, what are the personnel benefits for ED and CSL:

I encourage discussion and modification of this proposal as soon as possible.