C.mmp

The C.mmp was an early multiprocessor MIMD developed at Carnegie Mellon University by William Wulf (1971). The notation C.mmp came from the PMS notation of Bell and Newell, where a CPU was designated as C and a variant was noted by the dot notation; mmp stood for Multi-Mini-Processor

Sixteen PDP-11 minicomputers have been used in the process (named Compute Modules in the system). Each CM had a local memory of 8K and a local set of peripheral devices. One of the challenges has been made available by its unique connected processor, so the I / O system (designed by Roy Levin) hid the connectivity of the devices and the routing of the requests to the hosting processor. If a processor went down, the devices became unaccountable, which became a problem in overall system reliability. Processor 0 (the boot processor ) had the disk drives attached.

Each of the Compute Modules shared these communication pathways:

  • An interprocessor bus – used for distribution of system-wide clock, interrupt and process control messaging among the CMs
  • A 16×16 crossbar switch – used to connect the 16 CMs on one side and 16 banks of shared memory on the other. If all 16 processes were accessed, the memory would be competing. If two or more processors were trying to access the same bank of memory, one of them would be granted access to one cycle and the remainder would be negotiated on subsequent memory cycles.

Since the PDP-11 only has an address space of 16-bits, it has been added to expand the address space to 25 bits for the shared memory space. The UniBus architecture provided 18 bits of address, and the two high-order bits were used to select one of four relocation registers which selected a bank of memory. Proper management of the relocation registers is one of the challenges of the kernel operating system.

The original design used magnetic core memory, but during its lifetime, higher performance dynamic RAM became available and the system was upgraded.

The original processors were PDP-11/20 processors, but in the final system, only five of these were used; The remaining 11 were PDP-11/40 processors, which were modified by having additional microcode space. All modifications to these machines were designed and built at CMU.

Most of the 11/20 changes were implemented in the motherboard, but because the PDP-11/40 was implemented in microcode, a separate “proc-mod” board was designed to intercept certain instructions and implement the protected operating system requirements. For example, it was necessary, for operating system integrity, that the stack pointer register never be odd. On the 11/20, this is done by clipping the lead to the low-order bit of the stack register. On the 11/40, any access to the stack was intercepted by the proc-mod board and generated an illegal data access trap the low-order bit was 1.

The operating system was called HYDRA . It was an ability -based object-oriented multi-user operating system. System resources were represented as protected by capabilities.

Among the programming languages ​​on this system was a subset of ALGOL 68 . This language was in fact more superset than a subset, as the features supporting parallelism were vastly improved, to make good use of the C.mmp. The operating system and most applications were written in the language Bliss-11, which required cross-compilation from a PDP-10. The Algol-68 compile ran on the Hydra operating system. There was very little assembly code used in the operating system.

Because overall system reliability depended on having 16 CPUs running, there were serious problems with overall hardware reliability; if the MTBF was one of 24 hours, then the overall system was 16/24 hours, or about 40 minutes. Many of these failures have been processed in the process. Considerable effort has been made to improve the reliability of the hardware, and when a processor was noticeably failing, it was partitioned out, and would run diagnostics for several hours. When it had passed a first set of diagnostics, it was partitioned back into an “I / O processor” and would not run application code (but its peripheral devices are now available); it continued to run diagnostics. If it passed these after several more hours, it was reinstated as a full member of the processor set. Similarly, if a block of memory (one page) was detected as faulty, it was removed from the pool of available pages, and until otherwise notified, the operating system would ignore this page. Thus, the operating system becomes an early example of afault-tolerant system, which would inevitably arise.

The machine is now on display on the floor of Wean Hall at Carnegie Mellon University.

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright computerforum.eu 2018
Shale theme by Siteturner