5 ms·

Control Data Corporation's CDC 6600

59 points by brian_herman 3y ago

082349872349872 3y ago
One of the 6600 designers said: > I suppose the picture of computing is of a topsy-turvy growth obeying laws of a commercial "natural" selection. This could be entirely accurate considering how fast it has grown. Things started out in a scholarly vein, but the rush of commerce hasn't allowed much time to think where we're going. — JET I was amazed to read some of what he wrote at the time about the 6600 design and consider how qualitatively modern it sounds (if one is willing to add zeros and change units where quantitatively needed).
- Animats 3y ago
  The CDC 6600 was really a rather simple machine; it just had multiple copies of some units. The CRAY-I was even simpler, but had 64 copies of some units. Both were designed by small teams and had simple instruction sets. The other extreme was the Pentium Pro, the first superscalar x86 CPU. I went to the talk at Stanford where the lead designer described the architecture. That was the most insanely complicated CPU built up to that time. People were thinking RISC was the future, because nobody could possibly get something as messy as x86 to go much faster by architectural means. But Intel brought it off. One of the speaker's graphs showed the number of engineers involved over time. That peaked around 3000 people. Just getting that many people to work together to design one tightly-coordinated thing was an impressive achievement.
  - rbanffy 3y ago
    > That peaked around 3000 people. The number directly from the Pentium team was 3000.0000000001 people at the highest point.
  - _a_a_a_ 3y ago
    > The CDC 6600 was really a rather simple machine; ... The CRAY-I was even simpler Pretty bold claim, can you explain why you believe this is so? > But Intel brought it off. Not by buying up and killing the Alpha AXP, oh no.
    - B1FF_PSUVM 3y ago
      The DEC Alpha was the swan song of Digital Equipment Corporation, which was bought by Compaq (a PC manufacturer that peaked in the 1990s), which was bought by HP. Intel had little to do with it.
      - pdw 3y ago
        I don't know the details, but from Wikipedia: "In May 1997, DEC sued Intel for allegedly infringing on its Alpha patents in designing the original Pentium, Pentium Pro, and Pentium II chips. As part of a settlement, much of DEC's chip design and fabrication business was sold to Intel."
        p_l 3y ago
        In the 1990s, especially latter half, Digital's leadership went on divestment-oriented business management, and managed to ultimately divest the company of its future.
        KerrAvon 3y ago
        In hindsight, weren't they basically finished by 1989? We'd be living in a different world if they'd put all the money from the VAX 9000 into RISC CPUs instead.
        convolvatron 3y ago
        there was a whole line of mips decstations. I think that part of the market was already saturated for them.
        p_l 3y ago
        Not really - Alpha was quite successful. My personal suspicion is that if instead of chasing quick returns through divestment that had worked on keeping a portfolio of products that drove sales for each other (for example, Rdb which to my understanding was fairly successful in some areas) the results might have been different. There's reason why so many places kept to Digital gear even after Compaq mishandling, then the Itanium and HP days, and not all of those were customers that had problematic rewrites blocking any migration (like customers dependant on VMS).
  - clamchowder 3y ago
    The original Pentium was the first superscalar x86 CPU. Superscalar just means you can execute faster than scalar (one instruction at a time), and the P5 could theoretically sustain 2 IPC. Of course it was in-order so cache misses would likely prevent you from getting there. The Pentium Pro was Intel's first out-of-order design. It's also superscalar. StackOverflow has a really funny post by Andy Glew, who worked on the Pentium Pro, noting that a scalar out-of-order machine could make sense in some corner cases. (https://stackoverflow.com/questions/10074831/what-is-general-difference-between-superscalar-and-out-of-order-ooo-execution https://stackoverflow.com/questions/10074831/what-is-general...)
    - dbcurtis 3y ago
      If you were an instruction pairing whiz, you could get pretty close to 2 IPC on the Pentium I for certain kernels. The thing that Seymour had going for him at CDC is that he didn't bother with synchronous exceptions. On x86 (I worked on a late 486, Pentium I, Pentium II and Itanium II) you absolutely must have synchronous exceptions for backward compatibility. Debugging an exception on 6600 was a hair-tearing exercise, because the PC point somewhere near, not at, the instruction that raised, and there may be a swiss-cheese window of instructions that did not complete somewhere before that. Loads of fun for one and all. (I used 6600/7600's while working on Cyber 203/205 at CDC).
  - allenrb 3y ago
    I think that’s not quite correct re: the Cray 1 having 64 copies of certain units. True, the vector registers did have 64 entries but the vector functional units were pipelined. They could return a result each cycle (once past the initial latency) but did not return 64 results simultaneously.
pinewurst 3y ago
[flagged]
- rbanffy 3y ago
  Check the date.
  - pinewurst 3y ago
    [flagged]
    - rbanffy 3y ago
      There will eventually be a deep dive. The 6600 is a thing to behold. I'd love if the software was easier to find online and unencumbered.
- clamchowder 3y ago
  That's an interesting take considering I read the old CDC brochures and docs, and wrote the article using the equivalent modern terms. For example, what their training manual calls "third-order conflicts" are called WAR (write-after-read) hazards today. "first-order conflicts" mean either a functional unit is busy or a RAW hazard. I hope people in the future will not default to assuming everything is AI generated, and instead do due diligence by looking at the sources and what's written. I took a lot of care to understand the original docs and reframe it in modern terms, even though it's an April Fools joke. But if no one cares maybe I should try using AI to generate stuff sometime.
  - pinewurst 3y ago
    It's the combination of brochure voice and usage of present tense that gave me that impression. If I was writing this description as a hominid, it would be past tense and in a neutral, third person voice.
    - clamchowder 3y ago
snakeyjake 3y ago
Perhaps one day the power of the CDC 6600 will be available to all who need, or merely want, it. One can dream...
uticus 3y ago
> Delivering precise exceptions that the operating system can resume from would be a ludicrous waste of precious logic. Instead, programmers should be honest about the storage their programs need, and get good at their job. ah the days of yore
ok123456 3y ago
http://www.bitsavers.org/pdf/cdc/cyber/books/DesignOfAComputer_CDC6600.pdf http://www.bitsavers.org/pdf/cdc/cyber/books/DesignOfAComput...
- clamchowder 3y ago
  Be sure to check out the training manuals like http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/6600_CPU_TrainingManual_Vol1_Mar67.pdf http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/6600_CPU_T... or http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/6600_CPU_TrainingManual_Vol2_Mar67.pdf http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/6600_CPU_T... too. I figured out a lot from those.
jandrese 3y ago
I liked the chart comparing the memory bandwidth against a modern video card, which of course had to be in log scale and was still enormously different.
monocasa 3y ago
I know it's an Apr1 post, but I'd honestly really like more historic supercomputer content from chipsandcheese; this was a great read.
nxobject 3y ago
A classic early example of superscalar execution.
- clamchowder 3y ago
  I don't know if the CDC 6600 can be considered superscalar. I called it scalar because it can never issue more than one instruction per cycle, and can thus never sustain faster-than-scalar execution. If you use a different definition of superscalar (just having concurrent operations in flight), then I guess that applies to the CDC 6600? Then it'd also apply to any pipelined core, including stuff like the Intel 486.
  - dbcurtis 3y ago
    I'm pretty sure the 6600 could issue multiple instructions per clock. A 60 bit word could hold 4 15 bit instructions, or for instructions that required an 18 bit immediate address, those took two 15 bit parcels. If there were no conflicts, I think you could issue multiple instructions in a clock. For instance, if Ax is the base address, and Bx is the stride, you could do A4 = A4 + B4 ; loading X4 by side-effect A3 = A3 + B3 ; loading X3 by side-effect X1 = X5 + X6 ; do an add of data loaded in the previous unroll of the loop A2 = A2 + B2 ; store X2 by side-effect, presumably computed in previous unroll All 4 of those fit in one 60 bit word. And if you are clever with loop unrolling and instruction timing, you can get a lot of overlap. The 6600 had dirt-simple opcodes that took about a week to memorize, but.... that was a long time ago, so sorry I can no longer assemble machine code in my head. Memory fading.....
johnklos 3y ago
April Fools or not, this is a wonderful writeup that makes for a wonderful contrast between historical computing and modern computing. Love it!
rhelz 3y ago
chuckle I got a chance to tour a CDC Cyber 205--one of the last in active use. And "tour" is the right word--we toured it like you'd tour a house. First and last computer I was ever...inside of. You'd go down this "hall", the walls full of millions of wires, carefully looped so that the signals wouldn't arrive too early (1 foot = 1 nanosecond, and you wanted all the signals of the bus to arrive at the same time, which meant the all the wires on the bus had to be the same length.) "There's the address bus, now down the hall there are two rooms, one is the ALU, the other is the optional square root calculating units.... Yeah, a whole "room" to calculate square roots. I guess they hadn't figured out the fast square root algorithm which DOOM used yet :-) Absolutely astounding artifact. It was like seeing the great pyramids.
- dbcurtis 3y ago
  Yeah, I worked on that beastie. It was huge. Getting around it to probe things took planning.
  - rhelz 3y ago
    I can't even imagine wiring that thing up. I get confused just wiring up a breadboard-sized circuit. And debugging it once it was wired up.....
herodotus 3y ago
Amusing, but nostalgic for me: my first job after graduating was working as a COBOL programmer for Control Data. This was while I was waiting to be accepted into graduate school at the University of Waterloo. I enjoyed working there. But was very happy to get accepted at Waterloo (and stop programming in COBOL).
dbcurtis 3y ago
Like many write-ups of the 6x00, it totally ignores the peripheral processor (PP) subsystem, which was both simple and innovative. The PP's were 10 independent processors, 12 bits wide, but with an 18 bit accumulator so that they could compute central memory addresses. Each had 4K of 12 bit words that stored both driver code and was used as I/O buffer. But.... there really were not 10, there was one copy of the PPU compute hardware, and 10 copies of the state that all the CDC old-timers referred to as "the PP barrel". It was just a big circular shift register, so the 10 PP's were actually just 10-way hardware multi-threaded. Yes, hardware multi-threading dates from 1957. There famously were not interrupts in the classical sense in the 6x00, but PP's could read and scribble anywhere in central memory, and they could compute an address and jam it into the CPU's PC. So in effect infinitely flexible vectored interrupts. 4Kx12 is not a lot of program space, so most I/O drivers consisted of one or more PP overlays that would be loaded depending on which I/O device was in use. If I recall correctly, the operator console required a PP full time -- the console being a couple of CRT's with shared X & Y DACs, and independent Z DACs, so they used vector fonts for everything. A second PP was full time dedicated to scheduling the other 8, at least in the common operating systems. (There were a bunch of operating systems... but I won't get into that.) Also... somebody (maybe Seymour himself?) worked out a 12 word boot loader... and PP0 had a switch panel of 144 toggle switches arranged in a 12x12 matrix. You could toggle in the bootloader once, and leave it forever. At boot time those 12 words were loaded into PP0 core.
- clamchowder 3y ago
  Well for me it was a matter of how much time it took. I spent enough time understanding the Central Processor with all the weird CDC-specific terms. I had to reread several times before I realized Increment instructions did load/store. Oh, and that "bootloader" was called "dead start". The peripheral processors were indeed a 10-way SMT thing, which they called a barrel processor. Each thread had three registers but they operated in really strange ways, and I just didn't figure that out. There were other details like bandwidth being tied to bank count, which I also didn't go into.
  - dbcurtis 3y ago

59 points by brian_herman 3y ago

One of the 6600 designers said: > I suppose the picture of computing is of a topsy-turvy growth obeying laws of a commercial "natural" selection. This could be entirely accurate considering how fast it has grown. Things started out in a scholarly vein, but the rush of commerce hasn't allowed much time to think where we're going. — JET I was amazed to read some of what he wrote at the time about the 6600 design and consider how qualitatively modern it sounds (if one is willing to add zeros and change units where quantitatively needed).

Animats 3y ago
The CDC 6600 was really a rather simple machine; it just had multiple copies of some units. The CRAY-I was even simpler, but had 64 copies of some units. Both were designed by small teams and had simple instruction sets. The other extreme was the Pentium Pro, the first superscalar x86 CPU. I went to the talk at Stanford where the lead designer described the architecture. That was the most insanely complicated CPU built up to that time. People were thinking RISC was the future, because nobody could possibly get something as messy as x86 to go much faster by architectural means. But Intel brought it off. One of the speaker's graphs showed the number of engineers involved over time. That peaked around 3000 people. Just getting that many people to work together to design one tightly-coordinated thing was an impressive achievement.
- rbanffy 3y ago
  > That peaked around 3000 people. The number directly from the Pentium team was 3000.0000000001 people at the highest point.
- _a_a_a_ 3y ago
  > The CDC 6600 was really a rather simple machine; ... The CRAY-I was even simpler Pretty bold claim, can you explain why you believe this is so? > But Intel brought it off. Not by buying up and killing the Alpha AXP, oh no.
  - B1FF_PSUVM 3y ago
    The DEC Alpha was the swan song of Digital Equipment Corporation, which was bought by Compaq (a PC manufacturer that peaked in the 1990s), which was bought by HP. Intel had little to do with it.
    - pdw 3y ago
      I don't know the details, but from Wikipedia: "In May 1997, DEC sued Intel for allegedly infringing on its Alpha patents in designing the original Pentium, Pentium Pro, and Pentium II chips. As part of a settlement, much of DEC's chip design and fabrication business was sold to Intel."
      - p_l 3y ago
        In the 1990s, especially latter half, Digital's leadership went on divestment-oriented business management, and managed to ultimately divest the company of its future.
        KerrAvon 3y ago
        In hindsight, weren't they basically finished by 1989? We'd be living in a different world if they'd put all the money from the VAX 9000 into RISC CPUs instead.
        convolvatron 3y ago
        there was a whole line of mips decstations. I think that part of the market was already saturated for them.
        p_l 3y ago
        Not really - Alpha was quite successful. My personal suspicion is that if instead of chasing quick returns through divestment that had worked on keeping a portfolio of products that drove sales for each other (for example, Rdb which to my understanding was fairly successful in some areas) the results might have been different. There's reason why so many places kept to Digital gear even after Compaq mishandling, then the Itanium and HP days, and not all of those were customers that had problematic rewrites blocking any migration (like customers dependant on VMS).
- clamchowder 3y ago
  The original Pentium was the first superscalar x86 CPU. Superscalar just means you can execute faster than scalar (one instruction at a time), and the P5 could theoretically sustain 2 IPC. Of course it was in-order so cache misses would likely prevent you from getting there. The Pentium Pro was Intel's first out-of-order design. It's also superscalar. StackOverflow has a really funny post by Andy Glew, who worked on the Pentium Pro, noting that a scalar out-of-order machine could make sense in some corner cases. (https://stackoverflow.com/questions/10074831/what-is-general-difference-between-superscalar-and-out-of-order-ooo-execution https://stackoverflow.com/questions/10074831/what-is-general...)
  - dbcurtis 3y ago
    If you were an instruction pairing whiz, you could get pretty close to 2 IPC on the Pentium I for certain kernels. The thing that Seymour had going for him at CDC is that he didn't bother with synchronous exceptions. On x86 (I worked on a late 486, Pentium I, Pentium II and Itanium II) you absolutely must have synchronous exceptions for backward compatibility. Debugging an exception on 6600 was a hair-tearing exercise, because the PC point somewhere near, not at, the instruction that raised, and there may be a swiss-cheese window of instructions that did not complete somewhere before that. Loads of fun for one and all. (I used 6600/7600's while working on Cyber 203/205 at CDC).
- allenrb 3y ago
  I think that’s not quite correct re: the Cray 1 having 64 copies of certain units. True, the vector registers did have 64 entries but the vector functional units were pipelined. They could return a result each cycle (once past the initial latency) but did not return 64 results simultaneously.

pinewurst 3y ago

[flagged]

rbanffy 3y ago
Check the date.
- pinewurst 3y ago
  [flagged]
  - rbanffy 3y ago
    There will eventually be a deep dive. The 6600 is a thing to behold. I'd love if the software was easier to find online and unencumbered.
clamchowder 3y ago
That's an interesting take considering I read the old CDC brochures and docs, and wrote the article using the equivalent modern terms. For example, what their training manual calls "third-order conflicts" are called WAR (write-after-read) hazards today. "first-order conflicts" mean either a functional unit is busy or a RAW hazard. I hope people in the future will not default to assuming everything is AI generated, and instead do due diligence by looking at the sources and what's written. I took a lot of care to understand the original docs and reframe it in modern terms, even though it's an April Fools joke. But if no one cares maybe I should try using AI to generate stuff sometime.
- pinewurst 3y ago
  It's the combination of brochure voice and usage of present tense that gave me that impression. If I was writing this description as a hominid, it would be past tense and in a neutral, third person voice.
  - clamchowder 3y ago

snakeyjake 3y ago

Perhaps one day the power of the CDC 6600 will be available to all who need, or merely want, it. One can dream...

uticus 3y ago

> Delivering precise exceptions that the operating system can resume from would be a ludicrous waste of precious logic. Instead, programmers should be honest about the storage their programs need, and get good at their job. ah the days of yore

ok123456 3y ago

http://www.bitsavers.org/pdf/cdc/cyber/books/DesignOfAComputer_CDC6600.pdf http://www.bitsavers.org/pdf/cdc/cyber/books/DesignOfAComput...

clamchowder 3y ago
Be sure to check out the training manuals like http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/6600_CPU_TrainingManual_Vol1_Mar67.pdf http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/6600_CPU_T... or http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/6600_CPU_TrainingManual_Vol2_Mar67.pdf http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/6600_CPU_T... too. I figured out a lot from those.

jandrese 3y ago

I liked the chart comparing the memory bandwidth against a modern video card, which of course had to be in log scale and was still enormously different.

monocasa 3y ago

I know it's an Apr1 post, but I'd honestly really like more historic supercomputer content from chipsandcheese; this was a great read.

nxobject 3y ago

A classic early example of superscalar execution.

clamchowder 3y ago
I don't know if the CDC 6600 can be considered superscalar. I called it scalar because it can never issue more than one instruction per cycle, and can thus never sustain faster-than-scalar execution. If you use a different definition of superscalar (just having concurrent operations in flight), then I guess that applies to the CDC 6600? Then it'd also apply to any pipelined core, including stuff like the Intel 486.
- dbcurtis 3y ago
  I'm pretty sure the 6600 could issue multiple instructions per clock. A 60 bit word could hold 4 15 bit instructions, or for instructions that required an 18 bit immediate address, those took two 15 bit parcels. If there were no conflicts, I think you could issue multiple instructions in a clock. For instance, if Ax is the base address, and Bx is the stride, you could do A4 = A4 + B4 ; loading X4 by side-effect A3 = A3 + B3 ; loading X3 by side-effect X1 = X5 + X6 ; do an add of data loaded in the previous unroll of the loop A2 = A2 + B2 ; store X2 by side-effect, presumably computed in previous unroll All 4 of those fit in one 60 bit word. And if you are clever with loop unrolling and instruction timing, you can get a lot of overlap. The 6600 had dirt-simple opcodes that took about a week to memorize, but.... that was a long time ago, so sorry I can no longer assemble machine code in my head. Memory fading.....

johnklos 3y ago

April Fools or not, this is a wonderful writeup that makes for a wonderful contrast between historical computing and modern computing. Love it!

rhelz 3y ago

chuckle I got a chance to tour a CDC Cyber 205--one of the last in active use. And "tour" is the right word--we toured it like you'd tour a house. First and last computer I was ever...inside of. You'd go down this "hall", the walls full of millions of wires, carefully looped so that the signals wouldn't arrive too early (1 foot = 1 nanosecond, and you wanted all the signals of the bus to arrive at the same time, which meant the all the wires on the bus had to be the same length.) "There's the address bus, now down the hall there are two rooms, one is the ALU, the other is the optional square root calculating units.... Yeah, a whole "room" to calculate square roots. I guess they hadn't figured out the fast square root algorithm which DOOM used yet :-) Absolutely astounding artifact. It was like seeing the great pyramids.

dbcurtis 3y ago
Yeah, I worked on that beastie. It was huge. Getting around it to probe things took planning.
- rhelz 3y ago
  I can't even imagine wiring that thing up. I get confused just wiring up a breadboard-sized circuit. And debugging it once it was wired up.....

herodotus 3y ago

Amusing, but nostalgic for me: my first job after graduating was working as a COBOL programmer for Control Data. This was while I was waiting to be accepted into graduate school at the University of Waterloo. I enjoyed working there. But was very happy to get accepted at Waterloo (and stop programming in COBOL).

dbcurtis 3y ago

Like many write-ups of the 6x00, it totally ignores the peripheral processor (PP) subsystem, which was both simple and innovative. The PP's were 10 independent processors, 12 bits wide, but with an 18 bit accumulator so that they could compute central memory addresses. Each had 4K of 12 bit words that stored both driver code and was used as I/O buffer. But.... there really were not 10, there was one copy of the PPU compute hardware, and 10 copies of the state that all the CDC old-timers referred to as "the PP barrel". It was just a big circular shift register, so the 10 PP's were actually just 10-way hardware multi-threaded. Yes, hardware multi-threading dates from 1957. There famously were not interrupts in the classical sense in the 6x00, but PP's could read and scribble anywhere in central memory, and they could compute an address and jam it into the CPU's PC. So in effect infinitely flexible vectored interrupts. 4Kx12 is not a lot of program space, so most I/O drivers consisted of one or more PP overlays that would be loaded depending on which I/O device was in use. If I recall correctly, the operator console required a PP full time -- the console being a couple of CRT's with shared X & Y DACs, and independent Z DACs, so they used vector fonts for everything. A second PP was full time dedicated to scheduling the other 8, at least in the common operating systems. (There were a bunch of operating systems... but I won't get into that.) Also... somebody (maybe Seymour himself?) worked out a 12 word boot loader... and PP0 had a switch panel of 144 toggle switches arranged in a 12x12 matrix. You could toggle in the bootloader once, and leave it forever. At boot time those 12 words were loaded into PP0 core.

clamchowder 3y ago
Well for me it was a matter of how much time it took. I spent enough time understanding the Central Processor with all the weird CDC-specific terms. I had to reread several times before I realized Increment instructions did load/store. Oh, and that "bootloader" was called "dead start". The peripheral processors were indeed a 10-way SMT thing, which they called a barrel processor. Each thread had three registers but they operated in really strange ways, and I just didn't figure that out. There were other details like bandwidth being tied to bank count, which I also didn't go into.
- dbcurtis 3y ago