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.
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.
For sure. I remember thinking.... "But where are the instructions to load and store X registers?" -- Psych! There aren't any! Just jam an address into a A register. Take that you RISC fan-boys, can you get to less than zero instructions?
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.
> 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).
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.
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.
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).
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.
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.
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."
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.
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).
I am still not sure what the killer app was for the Alpha. Other than OpenVMS/Alpha to provide the business continuity for existing VMS customers, DEC was not really all that successful with the Alpha from that perspective.
Yes, Windows NT Alpha did take off initially and was the go-to non-Intel platform for CPU hungry apps, but it was expensive and then Intel caught up with multi-processor Pentium Pro systems and that was the end of the Alpha.
Sun SPARC/UltraSPARC was effectively a hardware appliance to run the Oracle database (and SAP). SGI/MIPS covered the 3D graphics market. IBM POWER was the hardware to run DB2 and other IBM wares ported from mainframes for customers who did not want to have to deal with JCL and other hairy stuff. HP PA-RISC was an enigma that ran something although not that many people were sure what exactly it was. HP Superdome was pretty rad tho – I worked on a project for a telco that had purchased a 128 CPU Superdome to run their billing system on (ironically, it was IBM who had sold them on the Superdome). HP-UX before v11.21 had been buggy AF and overall an abomination.
Yes, Alpha could run Oracle as well, plus other things… they never seem to have taken off tho, and Alpha was quickly relegated to an IP garage sale.
From the technology perspective, Alpha was a resounding success, at least in the beginning.
The hardware appliance for Oracle was Itanium on HP-UX. Oracle pushing it as recommended platform until their Sun acquisition is pretty much what kept it afloat after introduction - if the billing system used Oracle RAC as backend, it might be the reason for using Superdome.
From my perspective, Alpha had quite wide user base, not as much as Sun which seemed to have figured desktop unix sales way better than everyone else. I know some segments tended to buy Digital because if you knew what you wanted, Digital would let you simply order it - disappearance of that approach, forcing everyone to go through a sales rep, has been anecdotally pointed to me as why a bunch of places migrated post Compaq acquisition.
> hI am still not sure what the killer app was for the Alpha
It was a general purpose processor, talking about a single killer app doesn't make sense. It was designed for speed and expandability and as such seemed very successful.
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.
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).
> 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.
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.
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.....
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.
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.
Have you considered the date (4/1)? Maybe that has something to do with why an article about a 1960s thing is written in present tense?
If describing how an architecture works is "brochure voice" then I guess pretty much any technical deep dive is. Not sure how to avoid that.
Serious question now, would a company's brochure call out that their functional units are not pipelined? Because none of their original documentation did.
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.