CERN Accelerating science

This website is no longer maintained. Its content may be obsolete. Please visit for current CERN information.

CERN home pageCERN home pageDocuments by ReferenceDocuments by ReferenceCNLsCNLsYear 2001Year 2001Help, Info about this page


Editorial Information
If you need help
Announcements Physics Computing Desktop Computing Internet Services and Network Scientific Applications and Software Engineering Desktop Publishing The Learning Zone User Documentation Just For Fun ...
Previous:Once Upon a Time... The Mainframe Era
Next:A SHIFT in Outlook
 (See printing version)

35 Years Ago - the Control Data 6600

Julian Blake , IT/PDP


When CDC ruled the computing playground...

I arrived at CERN in October 1966, and started work as a system programmer on the Control Data (CDC) 6600. It is instructive to compare some of the characteristics of this computer with the computers we have today.

The CDC 6600 had one central processor (CP) and ten peripheral processors (PPs). There was one central memory (CM), and a private peripheral memory (PM) for each PP. There were twelve input/output channels and some pseudo channels. The CP could access its own registers and CM, but nothing else. A PP could access its accumulator register, its PM, the CM, and the I/O channels. A PP could also "exchange jump" the CP; this single instruction stopped the running CP program and started another, by exchanging the contents of the CP registers with a CP-register-image in CM. In practice one PP acted as system monitor (MTR, the heart of the operating system), another ran the operator's console (DSD, dynamic system display), and the remaining PPs constituted a pool of I/O processors. A CP program would place an I/O request in a mailbox, MTR would find the request, and allocate one of the pool PPs to perform it.

The operating system did not depend on interrupts. PP programs, notably MTR and the peripheral memory resident (PMR) in the pool processors, polled mail boxes for requests for action. The operating system ran wholely in PPs, with one exception: the memory move program, which relocated programs in CM to make space for an incoming program. The memory move program was effectively an extension of MTR running on the CP.

The CP was recognizably a RISC processor. It had multiple registers (18-bit address (A) and index (B) registers, 60-bit data (X) registers), a three address order code with 64 distinct instructions, and multiple functional units with pipelined execution. There were instructions for integer and floating point arithmetic, boolean operations and shifts, but no character manipulation instructions. Ones-complement arithmetic was used for integers and for floating point numbers. The floating point number format was proprietary, and included representations for infinity and undefined (as in today's IEEE floating point formats). CM consisted of 60-bit words, and was word addressed. By convention, a character occupied six bits and was represented in a proprietary "display code" containing digits, upper case letters, arithmetic and punctuation symbols, space and newline.

The 6600 CP had an 8-word instruction stack which functioned rather like an instruction cache, but without the flexibility of a modern cache. Program optimization consisted of allocating heavily used variables to registers, loading operands from memory a few instructions before they were needed, writing operands to memory a few instructions before their registers were needed to hold new operands, keeping several functional units busy simultaneously, and trying to get inner loops to fit into the instruction stack. The divide instruction was notorious, because it took about thirty clock cycles and its functional unit was not pipelined. The peak CP instruction rate was one instruction every 100 nanosecond clock cycle.

The ten peripheral processors worked with 12-bit words, but had an 18-bit accumulator which could hold a CM address. Instructions occupied one or two words, and could use any of the first 64 words of PM as an index register. There were 63 distinct instructions in the order code. Instructions included integer addition and subtraction, boolean operations and shifts, block and single word I/O operations on the 12-bit channels, block and single word read from and write to CM, and the exchange jump. Ones-complement arithmetic was used.

The ten PPs shared the same processor, in a cyclic manner. Each PP was served for 100 nanoseconds every microsecond. This sharing was invisible to the programmer.

Each PM contained 4096 12-bit words, which had to hold the PMR code, device driver code and a buffer for device data. Block sizes for disk and magnetic tape were limited by the size of PM. Complex code, such as that used to recover from magnetic tape I/O errors, was divided into a number of overlays, with only one overlay in memory at a time. Device drivers had to perform many of the operations that would nowadays be performed by firmware in a device's controller.

So how did one program the CDC 6600? The users wrote programs in FORTRAN IV. The CERN program library was written mainly in FORTRAN, but included some optimized routines written in assembly language. For detailed optimization, there was a CERN-written program to simulate the operation and timing of the 6600 CP. Large programs had to be divided into overlays, since there was no paging of memory. All memory was real, and each program was responsible for loading its overlays.

The operating system was written in PP assembly language, with small bits in CP assembly language. The initial assemblers (ASCENT for CP, ASPER for PP) were soon replaced by Control Data's COMPASS macro assembler, which provided a comprehensive listing of the machine code which it generated. The CP and PP order codes were simple and regular enough that it was not difficult to understand their assembly languages. CP code was the more difficult of the two, because the CP had 24 registers (8 each of A, B and X). The operating system was divided into overlays small enough to fit into PM, so each overlay was of an understandable size.

What did one do when the operating system went wrong? Provided DSD was still running in its PP, one could get a lot of information from the operator's console, which consisted of two alphanumeric displays and a keyboard. The system dayfile (log file) was a good source of diagnostic messages for predictable errors. After a crash or hang-up, one could take a dead start dump: the computer was rebooted, and printed the contents of some or all of the ten PMs and the CM in octal on a line printer. One learnt to look for the zero word in peripheral memory, which identified the PP's program counter value at the time of reboot. One learnt also to look for a particular bit dropped in every 32nd word of CM, which indicated a bad memory line driver module for that bit in that memory bank.

There was no read-only memory in the 6600. The dead start bootstrap program was set on 12 rows of 12 toggle switches. The contents of the switches was loaded into the start of PM0 to begin the bootstrap process. Changing the dead start panel switches without warning the next operator of the computer was considered an unfriendly act.

The input/output devices attached to CERN's 6600 in 1966 were a hard disk, several half inch and one inch magnetic tape units, a card reader, a card punch and a line printer.

Readers who are interested in digging further, can find a fair amount of information about the CDC 6600 on the Web (ask Google to search for "CDC6600"). There are photographs at and at There is technical information at

About the author(s): Julian Blake wrote a program loader and a memory scheduler for CERN SCOPE, which was CERN's derivative of Control Data's Chippewa and 6000 SCOPE 2.0 operating systems.

For matters related to this article please contact the author.

Vol. XXXVI, issue no 1

Last Updated on Thu Apr 05 15:28:10 CEST 2001.
Copyright © CERN 2001 -- European Organization for Nuclear Research