The term RISC was coined more than 15 years later, and the first RISC CPU, i.e. IBM 801, was designed several years before the introducing of the term "RISC".
IBM 801 deserves to be called the first RISC machine, because its design methodology had the explicit goal of achieving a greater performance than IBM 370, by simplifying its instruction set, and it introduced all the principles later endorsed in the Berkeley and Stanford RISC designs (which later evolved into SPARC and MIPS).
CDC 6600 was not created by the simplification of an earlier architecture. It was more complex than the previous very simple CDC computers.
Nonetheless, it was designed to achieve the maximum performance permitted by the available technology and both James E. Thornton and Seymour Cray were extremely competent computer designers, so many of their design decisions coincide with those that were also preferred many years later for the RISC CPUs.
It should be noted that CDC 6600 had a simple instruction set relying on fast register-to-register operations, but nonetheless its ISA was not too simple, as in some misguided RISC designs. For example, it was one of the first, if not the first ISA which included indexed addressing with auto-update of the address register, which are very useful for implementing maximum-performance loops that access arrays (instruction pair fusion is a greatly inferior solution to having 1 bit per load/store instruction specifying auto-update).
IBM 801 also had addressing modes with auto-update, which were inherited from it by ARM, HP PA-RISC and IBM POWER. Aarch64 has also inherited them from 32-bit ARM. While x86-64 has addressing with auto-update only in a few special instructions, it has an alternative method for achieving the same performance in most cases, by having indexed addressing with up to 3 components and with scaled indices (taken from DEC VAX). This allows the use of the loop counter as also the index register for accessing multiple arrays, which eliminates the need for separate index updating instructions.
The CDC 6600 ISA also included the instruction originally proposed by Alan Turing and implemented in the Ferranti Mark 1 computer (as "sideways add"), which was later renamed as "population count" in the Cray 1 ISA, and which was added to the x86-64 ISA by the AMD Barcelona CPUs, and later by the Intel Nehalem CPUs. It is said that this instruction was added to CDC 6600 due to a request from NSA, which then became an important customer for the CDC supercomputers, and later for the Cray supercomputers.
True, but a lot of resources are still wasted in the instruction cache and instruction decoder, with 2 instructions instead of 1.
Any superscalar CPU has limits on the number of instructions that can be fetched, decoded, renamed and dispatched and having 2 instructions instead of 1 for each load and store in an array processing loop can exceed any of those limits and slow down the execution, even when there are enough ALU/AGU execution units available.
This is why all mainstream ISAs either implement the CDC 6600 and IBM 801 solution, with auto-update of the index registers, or the DEC VAX solution with indexed addressing with scaled indices and up to 3 components (base + index + displacement).
The auto-update variant always allows loops with a minimum number of instructions, while scaled indexed addressing allows loops with a minimum number of instructions in the majority of cases, if appropriate data structures are used (i.e. SoA).
"You need a little bit of logic... and programmer here and there"
--
"So, let me tell you a little bit, a few of the problems, that ah, and the solutions that I see in building large computers.
First of all... I think that building large computers should be done with the fewest possible people.
One is perfect, but you can't quite work with one.
So.. the next best thing is about 12."
"The reason you need 12 is you kind of need one person from each of the disciplines that are necessary.
You need a mechanical engineer to build the box that it'll go in.
You need an electrical engineer to put the circuit together.
You need a little bit of logic... and programmer here and there
And you need a secretary of course.
But not very many."
Cray had a funny quote on the virtues of fast CPUs over parallelism "If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?". Of course history has shown that the "chickens" was the strategy the field went with.
This is only half of it. There is a limit of how strong an ox can be, and, at some point (on the way to the Cray 3) Seymour hit it. That limit is pretty close to how strong a chicken can be, and we just got breed chicken that are as strong as Seynmour's best oxen - which got us to a problem: the only way forward was with lots of ox-sized supechicken.
Someone should make that imagery into an educational video.
Due to CDC 6600, IBM lost almost completely the market for what today would be called high-performance computing, which was then dominated for 3 decades by CDC and then by Cray, after Seymour Cray left CDC.
However, during that time the market for lower-cost and acceptable performance computers was expanding very quickly, so IBM had growing revenues and profits, without being affected by the loss of a smaller market.
They were more strongly affected by the ascension of DEC, as the main vendor of minicomputers, which took the lower end of the market from IBM, but the medium-performance market, especially for business data processing, where the greatest profits were achievable, remained dominated by IBM, so they had little to worry about.
As a response to CDC 6600, IBM had the internal development project ACS (Advanced Computer Systems), which was eventually cancelled, as diverting resources from the money maker that was the IBM System/360 line.
Had ACS not been cancelled, it would have had good chances to become the fastest computer of the world, because its design team invented many techniques that were introduced in computers only almost a quarter of century later, e.g. unrestricted out-of-order and superscalar execution with fine-grained multi-threading.
The 6600, and no doubt Watson was lectured on it, was an extremely specialised machine - it had 60 bit words and that was it. No bytes, shorts, or anything similar. It was designed for floating point math. IBM had machines for science and business that were entirely different and incompatible prior to the 360.
It also was built with discrete transistors - no ICs in it at all. My first programming class at Purdue used the CDC6500 & 6600 with punch cards. Purdue's old 6500 is now in a museum in Seattle.
> IBM had resources to design and market yet for some reason it couldn't.
In many ways, the 6600 would be unthinkable to IBM - it was a very limited machine, just ludicrously fast (and cool looking).
It's very normal to slow down new model releases so they don't cannibalize too much of the sales of previous established lines. CDC was a very lean company, while IBM had a lot of different lines to protect from their own disruption.
It's always an important thing to remember it's better to develop the product that will kill your cash cow, because someone will, and you don't want it to be your competition.
Classic example of a small very motivated team with free reigns vs committee development at IBM. The irony is that less than 20 years later IBM would do the same thing and it lead to the IBM PC.
Did IBM consider the PC a successful product? Especially over time it's eaten their bread and butter mainframe market and they pulled out of the end user computing to Lenovo. On the flip side if they didn't do it, others were already trying.
The most striking thing to me about IBM memos from this era is just how literate executives were. These days most VPs struggle to write a single sentence worth reading.
They also had secretaries (even more-so at the executive level) who would proof-read the letter and return it to the boss for their revision and/or signature. Contrast that with today where it's easy for someone to click send and off it goes, incomplete thoughts and grammar errors and all.
If you want to improve your communications - when you finish writing your email, leave it as a draft for 30-40 minutes. Then go back an re-read it with a fresh viewpoint.
If I can suggest - the USAF has a manual for this, which guides you in being clear, concise, and specific:
Related? I have several sets of old encyclopedias, Collier's from the 40's and World books from the 60's and 80's. It is very noticeable how much better the older articles are written.
And weird errata, while looking for an example the Wikipedia article on Collier's claims they started in 1949 while my copies have copyrights 1932 - 1944 so were probably printed 1944/45.
Many people from that era were well read and well spoken. He in particular sounded like he had some interesting life experiences: air force pilot, ambassador to the Soviet Union, president of the Boy Scouts, etc.
I worked for a government entity and was involved in a lawsuit based on a very old, not-IBM mainframe contract that was solicited before I was born and amended like 30 times.
The memos and letters in those files were both amazing and depressing, as when you fast forwarded from the late 70s to circa 2010, the writing quality steadily declined.
I used CDC computers 1986-92. They sucked, and CDC employees could not comprehend that they sucked. They had convinced themselves that their alternate universe was real.
The 180/990 and the 205 were a pretty good FORTRAN vector machines if that was the problem you wanted to solve; the compiler was quite good. The other 170/180s were...for everything else...not so much. That boat had sailed.
One can argue that CDC was obliviously dead by the early 70s.
Incompatible, increasingly archaic platforms, the best of those optimal for batch Fortran number crunching, counter to industry growth/interest. Organizational metastasis with a next gen platform (Cyber 180 as Star was stillborn - CISC from hell as 2nd system(s) syndrome) only at the end of the decade. Standards, coupled with profound organizational incompetence, ground it to dust. They made really good OEM disk drives for a while but sold the business off to fund their continuing failures.
There really needs to be a history that’s not an encomium to William Norris, Philosopher King of CDC.
So the CDC 6600 wasn't considered a RISC machine, but a precursor?
The term RISC was coined more than 15 years later, and the first RISC CPU, i.e. IBM 801, was designed several years before the introducing of the term "RISC".
IBM 801 deserves to be called the first RISC machine, because its design methodology had the explicit goal of achieving a greater performance than IBM 370, by simplifying its instruction set, and it introduced all the principles later endorsed in the Berkeley and Stanford RISC designs (which later evolved into SPARC and MIPS).
CDC 6600 was not created by the simplification of an earlier architecture. It was more complex than the previous very simple CDC computers.
Nonetheless, it was designed to achieve the maximum performance permitted by the available technology and both James E. Thornton and Seymour Cray were extremely competent computer designers, so many of their design decisions coincide with those that were also preferred many years later for the RISC CPUs.
It should be noted that CDC 6600 had a simple instruction set relying on fast register-to-register operations, but nonetheless its ISA was not too simple, as in some misguided RISC designs. For example, it was one of the first, if not the first ISA which included indexed addressing with auto-update of the address register, which are very useful for implementing maximum-performance loops that access arrays (instruction pair fusion is a greatly inferior solution to having 1 bit per load/store instruction specifying auto-update).
IBM 801 also had addressing modes with auto-update, which were inherited from it by ARM, HP PA-RISC and IBM POWER. Aarch64 has also inherited them from 32-bit ARM. While x86-64 has addressing with auto-update only in a few special instructions, it has an alternative method for achieving the same performance in most cases, by having indexed addressing with up to 3 components and with scaled indices (taken from DEC VAX). This allows the use of the loop counter as also the index register for accessing multiple arrays, which eliminates the need for separate index updating instructions.
The CDC 6600 ISA also included the instruction originally proposed by Alan Turing and implemented in the Ferranti Mark 1 computer (as "sideways add"), which was later renamed as "population count" in the Cray 1 ISA, and which was added to the x86-64 ISA by the AMD Barcelona CPUs, and later by the Intel Nehalem CPUs. It is said that this instruction was added to CDC 6600 due to a request from NSA, which then became an important customer for the CDC supercomputers, and later for the Cray supercomputers.
> "some misguided RISC designs"
But when superscalar came around, such a RISC can execute the address update instruction concurrently with the memory access instruction.
True, but a lot of resources are still wasted in the instruction cache and instruction decoder, with 2 instructions instead of 1.
Any superscalar CPU has limits on the number of instructions that can be fetched, decoded, renamed and dispatched and having 2 instructions instead of 1 for each load and store in an array processing loop can exceed any of those limits and slow down the execution, even when there are enough ALU/AGU execution units available.
This is why all mainstream ISAs either implement the CDC 6600 and IBM 801 solution, with auto-update of the index registers, or the DEC VAX solution with indexed addressing with scaled indices and up to 3 components (base + index + displacement).
The auto-update variant always allows loops with a minimum number of instructions, while scaled indexed addressing allows loops with a minimum number of instructions in the majority of cases, if appropriate data structures are used (i.e. SoA).
Interesting to note the question had the answer all along. How would a modest effort outrun a vast organisation?
I never imagined he’d be caught by that mistake.
Cray's reply was sardonic: "It seems like Mr. Watson has answered his own question."
https://en.wikipedia.org/wiki/CDC_6600
Cray must have been a very funny person.
"You need a little bit of logic... and programmer here and there"
--
"So, let me tell you a little bit, a few of the problems, that ah, and the solutions that I see in building large computers. First of all... I think that building large computers should be done with the fewest possible people. One is perfect, but you can't quite work with one. So.. the next best thing is about 12."
"The reason you need 12 is you kind of need one person from each of the disciplines that are necessary. You need a mechanical engineer to build the box that it'll go in. You need an electrical engineer to put the circuit together. You need a little bit of logic... and programmer here and there And you need a secretary of course. But not very many."
https://managingdesignanddevelopment.blogspot.com/2022/09
Cray had a funny quote on the virtues of fast CPUs over parallelism "If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?". Of course history has shown that the "chickens" was the strategy the field went with.
Yeah, but only once they managed to breed chickens as strong as an ox.
This is only half of it. There is a limit of how strong an ox can be, and, at some point (on the way to the Cray 3) Seymour hit it. That limit is pretty close to how strong a chicken can be, and we just got breed chicken that are as strong as Seynmour's best oxen - which got us to a problem: the only way forward was with lots of ox-sized supechicken.
Someone should make that imagery into an educational video.
The Mythical Man-Month was only published in 1975.
He wasn't. The CDC 6600 cost IBM some prestige, but it didn't put a dent in IBM's sales, which were about to skyrocket due to the 360 series.
Due to CDC 6600, IBM lost almost completely the market for what today would be called high-performance computing, which was then dominated for 3 decades by CDC and then by Cray, after Seymour Cray left CDC.
However, during that time the market for lower-cost and acceptable performance computers was expanding very quickly, so IBM had growing revenues and profits, without being affected by the loss of a smaller market.
They were more strongly affected by the ascension of DEC, as the main vendor of minicomputers, which took the lower end of the market from IBM, but the medium-performance market, especially for business data processing, where the greatest profits were achievable, remained dominated by IBM, so they had little to worry about.
As a response to CDC 6600, IBM had the internal development project ACS (Advanced Computer Systems), which was eventually cancelled, as diverting resources from the money maker that was the IBM System/360 line.
Had ACS not been cancelled, it would have had good chances to become the fastest computer of the world, because its design team invented many techniques that were introduced in computers only almost a quarter of century later, e.g. unrestricted out-of-order and superscalar execution with fine-grained multi-threading.
The 6600, and no doubt Watson was lectured on it, was an extremely specialised machine - it had 60 bit words and that was it. No bytes, shorts, or anything similar. It was designed for floating point math. IBM had machines for science and business that were entirely different and incompatible prior to the 360.
It also was built with discrete transistors - no ICs in it at all. My first programming class at Purdue used the CDC6500 & 6600 with punch cards. Purdue's old 6500 is now in a museum in Seattle.
I think that misses the point of the memo. The 6600 was certainly something IBM had resources to design and market yet for some reason it couldn't.
> IBM had resources to design and market yet for some reason it couldn't.
In many ways, the 6600 would be unthinkable to IBM - it was a very limited machine, just ludicrously fast (and cool looking).
It's very normal to slow down new model releases so they don't cannibalize too much of the sales of previous established lines. CDC was a very lean company, while IBM had a lot of different lines to protect from their own disruption.
It's always an important thing to remember it's better to develop the product that will kill your cash cow, because someone will, and you don't want it to be your competition.
Classic example of a small very motivated team with free reigns vs committee development at IBM. The irony is that less than 20 years later IBM would do the same thing and it lead to the IBM PC.
Did IBM consider the PC a successful product? Especially over time it's eaten their bread and butter mainframe market and they pulled out of the end user computing to Lenovo. On the flip side if they didn't do it, others were already trying.
The most striking thing to me about IBM memos from this era is just how literate executives were. These days most VPs struggle to write a single sentence worth reading.
They also had secretaries (even more-so at the executive level) who would proof-read the letter and return it to the boss for their revision and/or signature. Contrast that with today where it's easy for someone to click send and off it goes, incomplete thoughts and grammar errors and all.
If you want to improve your communications - when you finish writing your email, leave it as a draft for 30-40 minutes. Then go back an re-read it with a fresh viewpoint.
If I can suggest - the USAF has a manual for this, which guides you in being clear, concise, and specific:
https://static.e-publishing.af.mil/production/1/saf_aa/publi...
Related? I have several sets of old encyclopedias, Collier's from the 40's and World books from the 60's and 80's. It is very noticeable how much better the older articles are written.
Here is an example from 1921, https://archive.org/details/colliersnewencyc01newy/page/40/m...
And weird errata, while looking for an example the Wikipedia article on Collier's claims they started in 1949 while my copies have copyrights 1932 - 1944 so were probably printed 1944/45.
Many people from that era were well read and well spoken. He in particular sounded like he had some interesting life experiences: air force pilot, ambassador to the Soviet Union, president of the Boy Scouts, etc.
I worked for a government entity and was involved in a lawsuit based on a very old, not-IBM mainframe contract that was solicited before I was born and amended like 30 times.
The memos and letters in those files were both amazing and depressing, as when you fast forwarded from the late 70s to circa 2010, the writing quality steadily declined.
I used CDC computers 1986-92. They sucked, and CDC employees could not comprehend that they sucked. They had convinced themselves that their alternate universe was real.
What...you didn't like NOS/VE?
The 180/990 and the 205 were a pretty good FORTRAN vector machines if that was the problem you wanted to solve; the compiler was quite good. The other 170/180s were...for everything else...not so much. That boat had sailed.
Very few NOS/VE haters, because very few ever used it. A dog with fleas.
That was many, many years after Cray had left. By the 80s, CDC was a shell of its former self.
One can argue that CDC was obliviously dead by the early 70s.
Incompatible, increasingly archaic platforms, the best of those optimal for batch Fortran number crunching, counter to industry growth/interest. Organizational metastasis with a next gen platform (Cyber 180 as Star was stillborn - CISC from hell as 2nd system(s) syndrome) only at the end of the decade. Standards, coupled with profound organizational incompetence, ground it to dust. They made really good OEM disk drives for a while but sold the business off to fund their continuing failures.
There really needs to be a history that’s not an encomium to William Norris, Philosopher King of CDC.