CDC 160 series

From Infogalactic: the planetary knowledge core
Jump to: navigation, search
File:Control Data 160-A.jpg
CDC 160-A with closeup of control panel

The CDC 160 series is a series of discontinued minicomputers built by Control Data Corporation. The CDC 160 and CDC 160-A are 12-bit minicomputers[1][2] built from 1960 to 1965; the CDC 160G is a 13-bit minicomputer, with an extended version of the CDC 160-A instruction set, and a compatibility mode in which it did not use the 13th bit.[3] The 160 was designed by Seymour Cray - reportedly over a long three-day weekend[citation needed]. It fit into the desk where its operator sat.

The 160 architecture uses ones' complement arithmetic with end-around carry.[4]

NCR joint-marketed the 160-A under its own name for several years in the 1960s.[5]

Overview

The CDC 160-A was a simple piece of hardware, and yet provided a variety of features which were scaled-down capabilities found only on larger systems. It was therefore an ideal platform for introducing neophyte programmers to the sophisticated concepts of low-level Input/output (I/O) and interrupt systems.

All 160 systems had a paper-tape reader, and a punch, and most had an IBM Electric typewriter modified to act as a computer terminal.[6][7][8] Memory on the 160 was 4096 12-bit words. The instruction set was small and RISC-like. The CPU had a 12-bit ones' complement accumulator but no multiply or divide. There was a full complement of instructions and several addressing modes. Indirect addressing was almost as good as index registers. The instruction set supported both relative (to the current P register) and absolute. The original instruction set did not have a subroutine call instruction and could only address one bank of memory.[1]

In the 160-A model, a "return jump" and a memory bank-switch instruction was added. Return-jump allowed simple subroutine calls and bank-switching allowed other 4K banks of memory to be addressed, albeit clumsily, up to a total of 32,768 words.[2] The extra memory was expensive and had to live in a separate box as large as the 160 itself. The 160-A model could also accept a multiply/divide unit, which was another large and expensive peripheral box.

In the 160 and 160-A, the memory cycle time was 6.4 microseconds. An add took two cycles. The average instruction took 15 microseconds, for a processing rate of 67,000 instructions per second.[1][2]

The 160G model extended the registers and memory words to 13 bits; in G mode, all 13 bits were used, while in A mode, only the lower 12 bits were used, for binary compatibility with the 160-A. The 160G added some instructions, including built-in multiply and divide instructions, and some additional addressing modes.[3][9]

Low-level I/O allowed control of devices, interfacing for determining device status, and for reading and writing data as either single bytes, or as blocks. I/O could be completed to a register, or to memory, or via a direct memory access (DMA) channel. The distinction between these I/O types was that regular I/O would 'hang' the CPU until the I/O operation completed, but DMA I/O allowed the CPU to proceed with instruction execution concurrently with the data transfer. The interrupt system was purely based on IO, meaning that all interrupts were generated externally. Interrupts were introduced to neophytes as being the alert mechanism by which a program could be informed that a previously initiated DMA I/O operation was completed.

Successors

The 160 architecture was modified to become the basis of the peripheral processors (PPs) in the CDC 6000 series mainframe computers and its successors. Large parts of the 160 instruction set were unchanged in the peripheral processors. However there were changes to incorporate the 6000 data channel programming, and control of the central processor. In the early days of the 6000s, almost the entire operating system ran in the PPs. This left the central processor unemcumbered by operating system demands and available for user programs.

References

  1. 1.0 1.1 1.2 Lua error in package.lua at line 80: module 'strict' not found.
  2. 2.0 2.1 2.2 Lua error in package.lua at line 80: module 'strict' not found.
  3. 3.0 3.1 Lua error in package.lua at line 80: module 'strict' not found.
  4. "A Programmer's Reference Manual for the CDC-160" by Douglas W. Jones
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Lua error in package.lua at line 80: module 'strict' not found.
  8. Lua error in package.lua at line 80: module 'strict' not found.
  9. Lua error in package.lua at line 80: module 'strict' not found.

External links