510 THE PDP-10 FAMILY
prototype for the current KL10/PDP-l1 front-end computer. Software modules were added to the Monitor to allow these synchronous lines to terminate remote PDP-8 and communication concentrator stations in simple point-to-point topologies. A remote station (e.g., line printer) is viewed by the user in the same manner as is a local printer.
With the KI10, a second front-end was produced which allowed BISYNC protocol of the IBM 2780 terminal to be used. However, most of our users were laboratory-oriented and wanted greater performance and functionality. Thus, concentrator/remote station capability including route-through (i.e., communication via multiple concentrators), and multiple hosts were added. These formed the basis of some of our understanding for subsequent DECnet protocol standards and functions. The use of DECsystem- 10 in the Advanced Research Projects Agency (ARPA) funded projects formed an other key base for our DECnet protocols and functions [Roberts, 1970].
DECnet-10 now provides the capability of having processes in different computers (including PDP-8s and PDP-11s) communicate with each other. These jobs appear to each other as I/O devices in the simplest applications.
Throughout all of this communication functionality evolution, the goal has been to free the user from concern with the link, communication mode, hardware location, and protocol.
Although we predicated the original PDP-6 hardware on multiprocessing, the Monitor was not designed explicitly for it. Lawrence Livermore Laboratory did build a two-processor system with their own operating system and special segmentation hardware. To meet the needs of the predominately scientific/computation marketplace in achieving higher processor through-put, a dual-processor KA10 was implemented using a master/slave scheme with wholly shared memory and one Monitor. The slave CPU scanned the queue of runnable jobs, selected one, and ran it. If a Monitor call was encountered, the job was placed in the appropriate queue and the Monitor located another runnable job. The "master" handled all I/O and privileged operations. In a CPU-bound environment, the dual processor provided approximately a 70 percent increase in system throughput.
An offshoot (and evolved design goal) of the dual-processor implementation was high availability. Monitor reconfigurability and bus-switching hardware allowed redundant components to be fully utilized during normal operation and, in the case of a hardware malfunction, to be separated into an operating configuration (with all available I/O) and a maintenance configuration (consisting of CPU, memory, and the faulty component).
At Carnegie-Mellon University (CMU), we proposed to build a 16 to 32 PDP-l0 structure [Bell et al., 1971]. It would have 16 Mwords of primary memory available via 16 ports at a bandwidth of 2.1 to 8.6 gigabits/second. With the use of processors larger than those of the KL 10, performance would have been over 50 million instructions per second (MIPS). The 16 processor, C.mmp [Wulf and Bell, 1972], based on PDP-11s at CMU, is a prototype of such a system.
Languages and Utilities
Monitor commands called the utilities and languages. The utilities, called CUSP (for Common User System Program), and languages included: EDIT, an editor for creating and editing a file from a user console; PIP, the peripheral interchange program to convert information among the I/O media and files; LOADER to load object modules; DESK, an interactive calculator; MACRO, an assembler; and FORTRAN II. Figure 1 shows these programs at various times, together with their origins.