CDC 6600

from Wikipedia, the free encyclopedia
Floor plan and elevation of the CDC 6600 with dimensions
The CDC 6600. Behind the system console there are two “arms” of the cross-shaped housing with open panels. Individual modules can be seen inside. The brackets of the modules are hinged to make the brackets behind them accessible. Each arm of the machine had up to four such brackets. The cooling system can be seen on the right.
System console of a CDC-6600 system. With this advanced design, screens and keyboards replaced the hundreds of switches and indicator lights found on the system consoles of the time. The software-controlled screens were used to display text in three selectable font sizes and were also able to draw simple graphics. Unlike modern raster graphics screens , the console had two vector screens ; in their font , each glyph consisted of a series of vectors. Auto-completion of keywords allowed faster command entry.

The CDC 6600 was the flagship of the mainframe systems from the CDC 6000 series from Control Data Corporation . Widely regarded as the first successful supercomputer , it beat the previous industry record holder, the IBM 7030 Stretch , by a factor of three. With an output of up to three  MegaFLOPS , the CDC 6600 was the fastest computer in the world from 1964 to 1969, when it lost this status to its successor, the CDC 7600 .

Many specimens were shipped to various nuclear weapons laboratories, and some found their way into university computer laboratories. A CDC 6600 is on display at the Computer History Museum in Mountain View, California . The only still working machine of the CDC 6000 series was restored at Living Computers: Museum + Labs in Seattle and can be used online there.

History and impact

CDC's first products were based on the machines developed at ERA , which Seymour Cray had to update after moving to CDC. After an experimental machine called Little Character , the CDC 1604 was shipped in 1960 , one of the first commercial transistor-based computers and one of the fastest machines on the market. The management was delighted and planned a new series of machines that were more tailored to business use. For example, they should include instructions on how to process characters and save records. Cray was not interested in such a project and set himself the goal of producing a new machine that would be 50 times faster than the 1604. When asked to produce a detailed report on plans one and five years ahead, he wrote back that his five-year goal was "to make the world's largest computer" - "the largest" at the time synonymous with "the fastest." ”- and his one-year plan was“ to have made a fifth of the way ”.

After moving to a new office near the original CDC headquarters, his core team began experimenting with high-quality versions of the "cheap" transistors that Cray had used in the 1604. After many attempts, they found themselves that transistors on germanium simply not allowed to operate much faster than in 1604. The "business machine" that the management originally wanted and now as a basis CDC 3000 series was formed, they provoked as far as possible. As a solution, Cray then decided to work with the then new silicon- based transistors from Fairchild Semiconductor , which had just come onto the market and offered a dramatically improved switching performance.

During that time, CDC grew from a startup to a large corporation, and Cray became increasingly frustrated with what he saw as ridiculous management requirements. The situation came to a head when the new CDC 3600 approached production readiness in 1962 and appeared to be exactly what management wanted and when they wanted it. Cray eventually told CDC CEO William Norris that something had to change or he would leave the company. Norris felt he was too important to lose and gave Cray the green light to set up a new lab wherever he wanted.

After a quick search, Cray decided to return to his hometown of Chippewa Falls, Wisconsin , where he bought a piece of land and opened a new laboratory.

Although this resulted in an extended delay in the design of his new machine, development in the new laboratory began quickly without any management intervention. At that time, the new transistors were becoming fairly reliable, and modules built with them mostly worked right the first time. The 6600 took shape, with Cray working with Jim Thornton, systems architect and "secret genius" of the 6600.

The first CDC 6600s were delivered to Livermore and Los Alamos in 1965 . They quickly became an indispensable system in scientific and mathematical computing circles, with systems supplied to the Courant Institute of Mathematical Sciences , CERN , the Lawrence Radiation Laboratory, and many others. A total of about 50 copies were delivered, according to other sources over 100.

Cray immediately turned to its successor model, which was to be shipped as the CDC 7600 , and set itself the goal of ten times the performance of the 6600. The later CDC Cyber 70 and 170 computers were very similar in overall design to the CDC 6600 and almost completely backward compatible.

The 6600 was three times faster than the previous record holder, the IBM 7030 Stretch ; this alarmed IBM . Then-CEO Thomas J. Watson, Jr. wrote a memo to his staff: “Last week Control Data announced ... the 6600 system. I understand that there are only 34 people working in the lab that is developing the system, including the caretaker. 14 of them are engineers and 4 are programmers… If I compare these modest efforts with our extensive development activities, I cannot understand why we lost our position as an industry leader by letting someone else offer the most powerful computer in the world. ”Cray's answer was sardonic: "It seems like Mr. Watson answered his own question."

description

Typical machines of the time used a single CPU to run the entire system. A typical program would first load data into main memory (often using prepackaged library code), process it, and then write it back. These diverse tasks required an extensive set of instructions and thus a complex CPU. This in turn implied a large CPU, which resulted in signal delays while information flowed between its individual modules. These delays limited the machine's performance; it could only work with a clock rate that allowed the signals to reach the next module in time.

Cray took a different approach. At the time, CPUs tended to run slower than the memory to which they were attached. For example, it took a processor 15 cycles to multiply two numbers while only one or two were required for each memory access. This meant that the memory was inactive for a significant amount of time. It was this idle time that the 6600 took advantage of.

The CDC 6600 used a simplified main processor that was designed so that it could perform math and logic operations as quickly as possible. To do this, it had to be made as small as possible in order to reduce the length of the cabling and the associated signal delays. This led to the (mostly) cross-shaped main housing of the machine, in which the circuit boards for the CPU were arranged near the center. The CPU was supported by ten peripheral processors, which were used for input / output and for data transfer to the CPU. The 6600 used a 60-bit word and one's complement representation of integers, which later CDC machines maintained until the late 1980s. This made them the last systems with such an architecture, alongside the UNIVAC 1100/2200 and some DSPs .

Instead of doing all computing and control tasks like other CPUs, the 6600 CPUs only performed arithmetic and logic operations. This allowed for a much smaller CPU that could operate at a higher clock speed. In combination with the higher switching speed of the silicon transistors, the new CPU design far surpassed all alternatives available at the time. The new design ran at 10 MHz (100 ns clock) about ten times faster than other machines on the market. The simple processor was not only faster, but also executed instructions in fewer clock cycles. For example, the CPU could perform a multiplication in ten cycles.

Peripheral processors (properties)

The CPU only had a limited set of simple instructions: while typical CPUs of the era had a complex set of instructions that also included instructions for all normal housekeeping tasks such as memory access and input / output , Cray implemented these commands on the 6600 instead, in separate, simpler "peripheral processors" (PPs) that were intended exclusively for such tasks. As a result, the CPU got by with a much smaller instruction set. This was the first implementation of what later became known as the Reduced Instruction Set Computer (RISC).

The parallel operation of CPU, peripheral processors (PPs) and I / O has increased the machine's performance considerably. Ordinarily, a machine with multiple processors would have cost much more. The key to the design of the 6600 was to make the PPs as simple as possible. They were based on the simple 12-bit CDC 160-A , which ran much slower than the CPU, collected data and transferred it as bursts to main memory via dedicated hardware at high speed .

The 10 PPs were implemented virtually; there was only one processor as hardware. This worked with 10 PP register sets, which represented the 10 PP instances (similar to modern multithreading processors) and were referred to as barrel . Figuratively speaking, the barrel “turned” step by step, with each PP register set being assigned to a slot in the PP CPU. The CPU carried out the command of the respective PP in whole or in part, whereupon the barrel “turned” again and the CPU assigned the register set (status) of the next PP. It took several "turns" of the barrel to process an instruction. A full barrel "turn" took 1000 nanoseconds (100 nanoseconds per PP), and an instruction took one to five "turns", or more in the case of a data transfer command.

Instruction set architecture

The 6600 CPU would be called a RISC system today, in which the processor is designed for comparatively simple commands that only have limited and precisely defined memory access. Many other machines use complex instructions - for example, fetching an operand from memory and adding it to a register by a single machine instruction. On the 6600, loading the value from memory required a separate command and adding a second. In theory, the additional memory accesses made processing slower, but this was offset by the fact that well-arranged code could process multiple commands at the same time. This simplification also forced programmers to be very aware of their memory accesses and therefore to code them carefully to reduce them as much as possible.

Models

The CDC 6000 series comprised four basic models: the CDC 6400, the CDC 6500, the CDC 6600 and the CDC 6700. They only differed in their CPUs, which were of two types, the 6400-CPU and the 6600- CPU. The 6400 CPU had a single, comprehensive processing unit and no separate processing units . Therefore the execution times of the statements could not overlap. For example, if an add instruction immediately followed a multiplication instruction in a 6400 CPU, the addition could not start until the multiplication was finished, so that the total execution time of the two instructions was the sum of their individual execution times. In contrast, the 6600 CPU had several arithmetic units that could work at the same time, i. H. " Parallel ", which allowed the CPU to overlap the execution times of the commands. For example, a 6600 CPU could start executing an addition instruction in the next CPU cycle after the start of a multiplication instruction (provided, of course, that the result of the multiplication was not an operand of the addition); therefore the total execution time of the two instructions was simply the (longer) execution time of the multiply instruction. The 6600 CPU also had something called an instruction stack , a type of instruction cache that helped increase CPU throughput by reducing the CPU idle time caused by waiting for memory to reload instructions. The two types of CPUs were instruction compatible, so that a program that could run on one of the two would also run on the other, but faster on the 6600 CPU. In fact, all models in the 6000 series were fully compatible with one another. The CDC 6400 had one CPU (one 6400 CPU), the CDC 6500 had two CPUs (both 6400 CPUs), the CDC 6600 had one CPU (one 6600 CPU), and the CDC 6700 had two CPUs (one 6600 CPU and a 6400 CPU).

Central processor (CP)

CDC register 6 × 00
5 9 . . . 1 7 . . . 0 0 (Bit position)
Operand register (60 bit)
X0 Register 0
X1 Register 1
X2 Register 2
X3 Register 3
X4 Register 4
X5 Register 5
X6 Register 6
X7 Register 7
Address register (18 bit)
  A0 Address 0
  A1 Address 1
  A2 Address 2
  A3 Address 3
  A4 Address 4
  A5 Address 5
  A6 Address 6
  A7 Address 7
Increment register (18 bit)
  B0 (all bits zero) Increment 0
  B1 Increment 1
  B2 Increment 2
  B3 Increment 3
  B4 Increment 4
  B5 Increment 5
  B6 Increment 6
  B7 Increment 7

The central processor (CP) and the main memory of the 6400, 6500 and 6600 machines had a word length of 60 bits. The CP had eight general-purpose 60-bit registers X0 to X7, eight 18-bit address registers A0 to A7, and eight 18-bit “increment” registers B0 to B7. B0 was kept permanently at zero by the hardware. Many programmers have found it useful to set B1 to 1 and similarly treat it as a fixed value.

There were no CP instructions for input and output; these were carried out via peripheral processors (PP, see below). There were also no separate opcodes for loading or saving between main memory and registers. Rather, this happened as a side effect of the assignment to certain A registers: By setting A1 to A5, the word at this memory address was loaded into X1 to X5; by setting A6 or A7, a word from X6 or X7 was saved. No side effects were associated with A0. A separate hardware load / store unit, the stunt box , performed the actual data movement independently of the instruction stream operation, so other operations could be completed while the memory was still being accessed; this required what, at best, eight cycles.

The 6600-CP contained ten parallel functional units with which several instructions could be processed at the same time. Today this is known as a super scalar processor design, but it was unique at the time. Unlike most modern CPU designs, functional units were not connected by pipeline. The functional unit was busy when it was given an instruction and remained so for the entire time it took to execute that instruction. (In contrast, in the arithmetic units of the CDC 7600 , the pipelining introduced.) At best, could all be given 100 ns a command to a calculator. The system read and decoded instructions from memory as quickly as possible, generally faster than they could be executed, and passed them on to the arithmetic and logic units for processing. These were:

  • Floating point multiplication (two instances)
  • Floating point division
  • Floating point addition
  • "Long" integer addition
  • Incrementer (two instances; performed memory load / save)
  • shift
  • Boolean logic
  • branch

Floating point operations were very important to this architecture: The CDC 6600 (and relatives) were practically the only ones able to perform a 60-bit floating point multiplication in a time comparable to that for a branch.

60-bit fixed point addition and subtraction were performed in the Long Add Unit , with negative numbers represented by their one's complement . The fixed point multiplication was carried out as a special case in the floating point multiplication unit. If the exponent was zero, the FP unit performed a 48-bit single-precision floating point multiplication and deleted the upper part with the exponent, producing a 48-bit integer result. The integer division was performed by a macro that converted to floating point numbers and back.

Previously executed instructions were stored in an eight word cache called the stack . In-stack jumps were faster than out-of-stack jumps because no memory fetch was required. The stack was cleared by an unconditional jump instruction, so that unconditional jumps at loop ends were usually written as conditional jumps that were always successful.

The system used a 10 MHz clock with a four phase signal. Floating point multiplication took ten cycles, division 29, and total performance, including memory delays and other issues, was about 3  MFLOPS . With the best available compilers, FORTRAN programs could count on a continuous output of around 0.55 MFLOPS towards the end of machine history.

Storage organization

User agents could only use a contiguous area of ​​main memory. The part of the memory that a running program had access to was determined by the registers RA (Relative Address) and FL (Field Length) to which the user program had no access. When a user program tried to read or write a word in main memory at address a, the processor first checked whether a was between 0 and FL-1. If this was the case, the processor accessed the word in main memory at address RA + a. This process was known as base-bound relocation . Every application program saw the main memory as a contiguous block of words with the length FL, starting with the address 0; in fact, the program could be anywhere in physical memory. With this technique, any application program could be moved by the operating system in main memory as long as the RA register reflected its position in memory. A user program attempting to access memory out of range (i.e., with an address no less than FL) interrupted and was terminated by the operating system. In this case, the operating system might create a core dump that recorded the contents of the program memory and saved it to a file so that the program developer could know what had happened. Note the difference to virtual storage systems ; in this case, the entire addressable memory space of a process must be in main memory, must be contiguous, and its size must not be larger than the actual memory capacity.

With the exception of the first seven copies of the CDC 6000 series , all devices could be configured with an optional Extended Core Storage (ECS) system. ECS was made from a different type of core memory than main memory, wired with only two wires per core as opposed to five wires for that. This made it slower than the main memory, but it was more economical to manufacture. Since it made very wide transfers, its sequential transfer rate was the same as that of main memory. A 6000 CPU could perform block memory transfers directly between a user's program (or operating system) and the ECS unit. Wide data paths were used, so this was a very quick operation. Similar to the main memory, the memory limits of the ECS were managed by the operating system with a relative address / field length mechanism. ECS could be used for a variety of purposes, including user data arrays that were too large for central storage to store frequently used files, for offloading, and even as a communication path in a multi-mainframe complex.

Peripheral processors (PPs)

To handle the "housekeeping" tasks that were assigned to the CPU in other designs, Cray added ten more processors, some of which were based on his earlier CDC 160-A computer. These computers, called peripheral processors or PPs, were full-fledged computers in their own right, but were optimized for I / O tasks and running the operating system. (Substantial parts of the operating system ran on the PPs, so that most of the central processor's performance remained available to user programs.) Only the PPs had access to the I / O channels. One of the PPs was in charge of overall control of the machine, including controlling the program that ran on the main CPU while the other was assigned various I / O tasks. When the CP program had to perform an operating system function, it made a request to a specific memory location (reference address + 1) which was monitored by PP0. If necessary, PP0 assigned another PP to load the required code and to process the request. The PP then cleared RA + 1 to inform the CP program of the completion of the task.

The special role of the PP0 in controlling the machine was a potential single point of failure , since in the event of its malfunction the entire machine could fail, even if the nine other PPs and the CPU were still functioning properly. Cray remedied this weak point in the design of the successor model 7600 by allowing each PP to be the controller and the CPU to assign this role to another.

Each PP had its own memory with 4096 12-bit words; this memory was used both for I / O buffering and for program storage. In contrast, the ten PPs used a common processor in a configuration called barrel and slot . This meant that the slot (processor) executed an instruction cycle of the first PP, then an instruction cycle of the second, and so on in a round-robin manner. This was done for cost reasons as well as because 10 PP clock cycles were required to access the CP memory: If a PP accessed the CP memory, the data was available the next time the PP received its slot time .

Word lengths, characters

The central processor had 60-bit words, while the peripheral processors had 12-bit words. CDC used the term byte for 12-bit units used by PP. The character length was 6 bits, and the instructions of the CP were either 15 bits or 30 bits with a signed 18-bit address field, the latter allowing a directly addressable storage space of 128K words of the central memory. (Expressed in modern 8-bit bytes, this was 0.94 MB.) The signed nature of the address registers limited a single program to 128K words. (Later CDC 6000-compatible machines could have 256K or more words of main memory if budget allowed, but individual user agents were still limited to 128K words.) CPU instructions had to start on a word boundary when they were targeted by a jump instruction or a subroutine return, sometimes requiring no-op instructions to fill in the last 15, 30, or 45 bits of a word. Experienced assembler programmers were able to optimize their programs by filling these no-op areas with other instructions that were needed later in the program.

The 6-bit characters in a coding called CDC Display Code could be used to store up to 10 characters in a word. They allowed a character set of 64 characters, sufficient for all capital letters, digits and some punctuation marks, and at least for writing FORTRAN or printing financial or scientific reports. In fact, the CDC display code was used in two variants - 64 characters and 63 characters. The 64-character set had the disadvantage that two consecutive colon characters were interpreted as the end of a line if they were at the end of a 10-byte word. A later variant, called 6/12 display code , was also used in the time-sharing systems KRONOS and NOS in order to use the complete ASCII character set largely compatible with older software.

Since there were no instructions for addressing bytes, you had to write code to wrap characters in words and move them around. The very large words and the comparatively small memory capacity meant that programmers often saved memory by packing data into words at the bit level.

Due to the long word length and 10 characters per word, it was often faster to process multiple words at once than to unpack, process and repackage them. For example, the CDC- COBOL compiler was quite good at processing decimal fields using this technique. Such techniques are often used today in the "multimedia" instructions of modern processors.

Physical design

A CDC-6600 logic module with 64 silicon transistors in Cordwood technology . The coaxial connectors are test connections. The module was cooled by conduction through the front panel. The CDC 6600 contained almost 6,000 such modules.

The machine was housed in a box shaped like a plus sign, with a pump and heat exchanger in the outermost 46 cm of the four arms. Cooling was done with Freon , which circulated in the machine and transferred heat to an external cooling water supply. Each arm could accommodate four chassis, each 20 cm thick, hinged near the center and opening like a book. The intersection of the “plus” was filled with cables connecting the chassis together. The chassis were numbered from one (with all ten PPs and their memories and the twelve rather minimal I / O channels) to 16. The main memory for the CPU was distributed over many chassis. In a system with only 64K words of main memory, one of the arms of the “plus” was omitted.

The logic of the machine was packaged in modules approximately 6.4 cm square and 2.5 cm thick. Each module had a connector (30 pins, two vertical rows of 15 each) on the back and six test ports on the front. The module was placed between two aluminum cooling plates to dissipate heat. It consisted of two parallel circuit boards, with the components either mounted on one of the circuit boards or between the two circuit boards. This resulted in a very high packing density - generally not be repaired, but with good heat transfer properties and as English cordwood construction known.

Operating system and programming

There was a sore point in the development of the 6600 operating system : missed deadlines. The machines originally had a very simple sequence control system called COS (Chippewa Operating System), which was quickly “thrown together” on the basis of the earlier CDC 3000 operating system in order to have something ready to run for system testing before delivery. However, the machines were supposed to come with a much more powerful system called SIPROS (Simultaneous Processing Operating System), which was developed in the company's System Sciences Division in Los Angeles . The customers were impressed by the list of functions from SIPROS, and many had SIPROS entered in their supply contracts.

SIPROS turned out to be a major fiasco. Development schedules continued to slide, costing CDC significant profits in the form of fines for delivery delays. After a few months of waiting with machines that were otherwise ready for dispatch, the project was finally canceled. The programmers who had worked on COS had little confidence in SIPROS and had continued to work on improving COS.

Operating system development was then split into two camps. CDC-sanctioned development of COS was carried out in the software development laboratory of Sunnyvale, California . Many customers eventually got their systems delivered with this software, which was then known as SCOPE (Supervisory Control Of Program Execution). SCOPE version 1 was essentially a disassembled COS; SCOPE version 2 supported new devices and file systems. SCOPE version 3 included support for permanent files, EI / 200 remote batch support, and INTERCOM time-sharing support. SCOPE always had significant reliability and maintainability problems.

CDC 6000 Series SCOPE 3.1 creates itself while running on the desktop CYBER emulator

COS “underground development” took place at the assembly plant in Arden Hills, Minnesota . MACE ([Greg] Mansfield and [Dave] Cahlander Executive) was largely written by a single programmer outside of business hours when machines were available. The functionality was essentially the same as the COS and SCOPE 1. The previous COS file system was retained, but the code modularity was greatly improved to improve system reliability and adaptability to new storage devices. MACE was never an official product, but many customers were able to get it from CDC.

The unofficial MACE software was later selected in place of the official SCOPE product as the basis for the next CDC operating system, KRONOS , which was named after the Greek god of time . It is said that Dave Mansfield called the University of Minnesota library and asked for an ancient word that means "time." He wrote "Kronos" instead of "Chronos". The main marketing reason was the development of the TELEX timeshare feature and the BATCHIO remote batch feature. Kronos continued to use the COS / SCOPE-1 file system and added a permanent file functionality.

NOS (Network Operating System) was developed as an attempt to standardize the SCOPE and Kronos operating system products. NOS should be the only operating system for all CDC machines, a fact that CDC strongly promoted. Many SCOPE customers continued to be software dependent on the SCOPE architecture, so CDC simply renamed it to NOS / BE (Batch Environment) and could claim that all users were running NOS. In practice it was much easier to change the Kronos code base to add SCOPE functionality than the other way around.

Other operating systems that were never intended for the customer were also manufactured in the vicinity of the assembly plant. This included the engineering tools SMM for hardware tests and KALEIDOSCOPE for software “smoke tests”. Another tool frequently used for testing by CDC field service technicians was MALET (Maintenance Application Language for Equipment Testing), which was used to stress test components and devices after repairs or service work by engineers. The test conditions often used hard disk packs and magnetic tapes that were deliberately flawed to determine whether the faults were recognized by MALET and the technician.

The names SCOPE and COMPASS were used by CDC for the CDC 6000 series including the 6600 as well as for the CDC 3000 series :

  • COMPASS was the name of the assembly languages in both families.
  • The operating systems of the 3000 and 6000 series were called SCOPE.

CDC 7600

The CDC 7600 was originally intended to be fully compatible with the existing 6000 series machines. It was originally referred to as the CDC 6800. However, during development, the developers realized that maintaining full compatibility with the existing 6000-series machines would limit the potential increase in performance and decided to sacrifice compatibility for performance. While the CPU of the CDC 7600 was essentially instruction-compatible with the CPUs 6400 and 6600 and enabled code portability at the source code level of the higher-level programming language , the hardware of the CDC 7600, especially that of its peripheral processor units (PPUs), was completely different. The CDC 7600 required a different operating system. This proved to be a boon as the designers were able to improve on some of the features of the 6000 design, such as the latter's complete dependence on peripheral processors (PPs), particularly the former (called PP0), to control the operation of the entire computer system including the CPU . In contrast to the 6600 CPU, the CPU of the CDC 7600 could control its own operation. In fact, the 6000 series machines have been upgraded with this feature .

literature

Web links

Individual evidence

  1. ↑ A sample of this peculiar font can be found on the cover of James E. Thornton: Design of a Computer - The Control Data 6600 . Scott, Foresman and Co, Glenview, IL 1970, LCCN  74-096462 ( bitsavers.org [PDF; accessed October 7, 2019]).
  2. ^ Andrew RL Cayton, Richard Sisson, Chris Zacher: The American Midwest: An Interpretive Encyclopedia . 2006, ISBN 0-253-00349-0 .
  3. ↑ Alexander Smith: CDC 6600 - Historical Interlude: From the Mainframe to the Minicomputer Part 2, IBM and the Seven Dwarfs - They Create Worlds . Retrieved October 7, 2019.
  4. ^ Making a World of Difference: Engineering Ideas into Reality . National Academy of Engineering, 2014, ISBN 0-309-31265-5 : "Designed by Seymour Cray, the CDC 6600 was almost three times faster than the next fastest machine of its day, the IBM 7030 Stretch."
  5. ^ Andreas Sofroniou: Expert Systems, Knowledge Engineering for Human Replication . 2013, ISBN 1-291-59509-0 : "In 1964 Cray's CDC 6600 replaced Stretch as the fastest computer on Earth."
  6. ^ Sebastian Anthony: The History of Supercomputers . April 10, 2012. Retrieved October 7, 2019.
  7. ↑ CDC 6600 computer . Encyclopædia Britannica. Retrieved October 7, 2019.
  8. ↑ Gordon Bell: A Seymour Cray Perspective . In: Seymour Cray Lecture Series . University of Minnesota . November 10, 1997. Retrieved October 7, 2019: “The 7600 design lasted longer than any other supercomputer design. It had the highest performance of any computer from its introduction in 1969 till the introduction of the Cray 1 in 1976. "
  9. ↑ CDC 6500 . Living Computers: Museum + Labs. Retrieved October 7, 2019.
  10. ^ Control Data Corporation, "Little Character" Prototype . Computer History Museum. Retrieved October 7, 2019.
  11. ^ The CDC 6600 arrives at CERN . January 14, 1965. Retrieved October 7, 2019.
  12. ↑ Lawrence and His Laboratory, ch. 6: Bumper Crop . Lawrence Berkeley Laboratory . 1996. Retrieved October 7, 2019.
  13. ↑ CDC 6600 . January 16, 1998. Archived from the original on January 4, 2001. Retrieved October 7, 2019.
  14. ^ Mark D. Hill, Norman P. Jouppi, Gurindar S. Sohi (Eds.): Readings in Computer Architecture . Morgan Kaufmann, 1999, ISBN 1-55860-539-8 , pp. 11 .
  15. ↑ An exact image of the memo appears in: Thomas J. Watson: Memorandum . August 28, 1963. Retrieved October 7, 2019.
  16. ^ Mark Smotherman, Dag Spicer: IBM's Single-Processor Supercomputer Efforts . In: CACM . tape 53 , no. December 12 , 2010, ISSN  0001-0782 , p. 28–30 ( acm.org [accessed October 7, 2019]).
  17. ↑ Hardware Reference Manual . Revision M. In: Control Data 6000 Series Computer Systems . No. 60100000 . Control Data Corporation , St. Paul, MN June 20, 1971 p. 4-3, 4-4 ( trailing-edge.com [PDF; accessed October 7, 2019]).
  18. ↑ Control Data 6400/6500/6600 Computer Systems Reference Manual . Revision H. Control Data Corporation, St. Paul, MN February 21, 1969 ( archive.org [accessed October 7, 2019]).
  19. ↑ This description applies to early versions of the CDC software; later versions used the Central Exchange jump (XJ) command to reduce the administrative overhead for functions that could be fully executed in the CP.
  20. ↑ The term display code was associated with CDC in a similar way to the way EBCDIC was originally associated with IBM. Other terms used in the computer industry were BCD and SIXBIT , the latter preferred by DEC .
  21. ↑ DEC / PDP character codes . University of Miami . Archived from the original on March 11, 2019. Retrieved October 7, 2019.
  22. ↑ KRONOS 2.1 Time-Sharing User's Reference Manual . Revision B. In: Control Data Cyber ​​70 Series Models 72/73/74, 6000 Series Computer Systems . No. 60407600 . Control Data Corporation , St. Paul, MN May 1, 1974 ( bitsavers.org [PDF; accessed October 7, 2019]).
  23. ↑ Speed ​​and Power (Understanding Computers) . Time Life Education, 1990, ISBN 0-8094-7587-1 , pp. 17 .
  24. ^ HD Pridmore: COMPASS Programming Training Manual . In: 3100 3200 3300 3500 Computer Systems . No. 60184200 . Control Data Corporation , St. Paul, MN 1967 ( archive.org [PDF; accessed October 7, 2019]).
  25. ↑ COMPASS Reference Manual . Revision C. In: 3600 Computer Systems . No. 60184200 . Control Data Corporation , St. Paul, MN December 1967 ( bitsavers.org [PDF; accessed October 7, 2019]).
  26. ↑ "CDC delivered an early version of their SCOPE operating system for the 3600" Ernest J. Henley, Jeffery Lewins (ed.): Advances in Nuclear Science and Technology . Volume 9. Academic Press , New York 1976, ISBN 0-12-029309-9 , pp. 309 ( limited preview in Google Book search).
predecessor Office successor
IBM 7030 Stretch World's most powerful computer
1964–1968 		CDC 7600