CDC 6600 Peripheral Processors: The Operating System's I/O Computers

The CDC 6600 is often remembered through its fast central processor and the scoreboard that let its functional units overlap independent operations. That account describes an important part of the machine, but it can leave a misleading picture of how the rest of the system worked. The central processor was not the computer’s only processor and did not directly manage ordinary peripheral traffic. Ten smaller, programmed peripheral processors (PPs) mediated input/output and performed much of the system-control work around it.

This was not simply a central CPU with a DMA engine attached. Each PP had its own local memory and instruction state, could execute control code, communicate with central memory, and operate one of the system’s shared I/O channels. Control Data’s programming manuals show how that hardware split became a software organization: a central program could reserve shared memory and request standard I/O operations from peripheral-processor programs without treating a tape drive, reader, or printer as a direct extension of its own instruction stream.

A second processor class divided the machine’s work

The CDC 6600 System Reference Manual and James E. Thornton’s 1964 description distinguish the central processor from the peripheral/control processors. The central processor manipulated 60-bit words in central memory. A peripheral processor worked with 12-bit words in its own local store; ten PPs were connected on one side to central memory and on the other to twelve bidirectional I/O channels. Each PP could execute instructions, including single-word or block transfers between its local memory and a channel or central memory.

The width difference was an architectural boundary, not merely a matter of naming. A 60-bit central-memory word was assembled from five 12-bit peripheral words in the documented transfer network. Programs exchanging records therefore had to respect both the transfer path and the representation used by the peripheral program. An engineer could not assume that an I/O channel delivered a fully formed central word directly into a central-processor register.

The 1964 paper explains the design motivation in explicit terms: the 6600’s central arithmetic was intended to remain isolated from peripheral activity. The executive control of the system was in one of the PPs while others handled assigned I/O or control work. The central processor interacted with that world through central memory and defined control mechanisms, including the exchange jump, rather than by taking over a device channel itself. This design does not mean I/O was free or instantaneous; it means control and transfer work could proceed in a processor subsystem built for those responsibilities.

The PPs were programmed agents, not just controllers

The PP instruction set was small beside the 6600 central processor’s 60-bit scientific instruction environment, but it was enough to perform real program work. Thornton documents 12- and 24-bit PP instruction formats, arithmetic and logical operations, conditional branches, channel transfers, central-memory transfers, and operations that could interrupt or monitor central-processor execution. The small word size and local memory made the PP a distinct execution environment with its own code and state, not a hidden central-processor mode.

The organization also avoided turning each peripheral into a unique attachment to the central processor. A PP program could handle channel ownership and data movement while a central program used its memory and arithmetic resources for the requested computation. Multiple PPs could operate against the shared channel pool, subject to the system’s actual assignment and control rules. In a system with several active devices, the important scheduling question was not only “How fast is the central processor?” but also “Which PP owns this channel, where is the transfer buffer, and how does the central job learn that the operation has completed?”

That is why “the PPs did I/O” is accurate but incomplete. They also participated in the operating system’s control path. One PP could maintain executive duties while other PPs performed specialized device or control assignments. The architecture separated where application arithmetic ran from where the machine’s external work was orchestrated, allowing both functions to be active without pretending they were one kind of instruction stream.

ASPER made the split usable by application programmers

The 1965 6600 Programming System, Volume II: ASPER manual documents an assembly system for peripheral-processor programs. Its preface describes facilities for both isolated PP programs and PP code synchronized with central-processor programs. ASPER could expose symbols from the associated central program, reserve central-memory words or blocks, support PP overlays, and provide system macros for requesting standard I/O operations from other PPs or loading additional PP programs.

These facilities reveal how the hardware boundary was meant to be crossed. A central program and its peripheral routines could share named memory and parameter structures while remaining separately executed programs. A central application could express a request through an agreed system interface; a PP-side service could then coordinate the channel operation and place transferred data in the reserved central-memory area. The interface was more structured than “write a device register and wait,” but it still required the program to define shared data, request ownership, completion conditions, and error handling.

For a historical reconstruction, keep three layers distinct:

Layer	Responsibility in the 6600 model	Evidence to inspect
Central processor	Scientific/application arithmetic and central-memory work	System reference and central program
Peripheral processor	Executing channel, transfer, and system-control code	PP instruction and ASPER manuals
I/O channel and device	Moving words to or from attached equipment	Channel assignment and device documentation

This table is a reading aid, not a complete operating-system specification. The manuals describe particular releases and configurations; they do not establish that every 6000-series or later CYBER machine used identical PP counts, channel assignments, or software procedures.

There is a useful modern analogy between a 6600 PP and an I/O processor or service processor: each takes programmed work off the main computational path and owns interactions with external devices. But the analogy stops at the functional boundary. The 6600 PPs were part of the machine’s core architecture, used a 12-bit instruction/data environment, shared central memory and channels according to CDC’s rules, and ran within the control organization of the contemporary system. They were not modern PCIe devices, independently secured management controllers, or general-purpose CPU cores with private operating systems.

It is also important not to confuse PP concurrency with the central processor’s scoreboard. The scoreboard tracked conflicts among the central processor’s functional units and registers; the PPs were separate programmed processors with separate local memories and channel responsibilities. Both mechanisms supported system-level parallelism, but one scheduled central arithmetic resources and the other partitioned I/O/control execution from central computation. The active article CDC 6600 Scoreboard: Reservations, Dependencies, and Parallel Execution covers the former in detail.

Reconstructing an I/O path from the records

To trace one historical job, begin with the CDC system reference manual for the hardware path, then consult the applicable peripheral-processor programming manual for instruction and memory conventions. Use the ASPER system macros and program organization to identify how a central routine requests a peripheral service. Finally, follow the assigned channel/device documentation and trace the point at which transfer state becomes visible in central memory or control state.

Record the PP program name and version, assigned channel, central-memory buffer reservation, direction and transfer length, request/response fields, error codes, and the central program’s synchronization point. If recreating behavior in a simulator, test empty input, short transfers, end-of-record handling, device failure, and overlapping requests from different PPs. A successful block copy is not enough to prove that the reconstructed system preserves channel ownership or the handoff to the central program.

The CDC 6600’s peripheral processors are historically significant because they made I/O and system control programmed parts of the architecture rather than peripheral chores left to the central scientific processor. The primary manuals show that this split reached all the way into the programming system. Reading the PP layer alongside the scoreboard gives a more complete picture of why the 6600 was a system of cooperating processors, not merely one fast CPU surrounded by devices.

Related:

Sources:

A second processor class divided the machine’s work

The PPs were programmed agents, not just controllers

ASPER made the split usable by application programmers

What this architecture does and does not share with modern systems

Reconstructing an I/O path from the records

Comments