> To achieve a profit for the ACS program, Amdahl asked IBM management to approve three ACS/360 models: the high-performance design, a 1/3 performance version, and a 1/9 performance version. He felt that these performance goals would be a good fit with the System 360 marketing plans. He remembers that IBM Corporate Marketing evaluated the targets and reported: "1) the supercomputer alone was a loss leader! 2) the supercomputer plus the 1/3 performance computer was break-even! And 3) the supercomputer plus both the 1/3 performance computer and the 1/9 performance computer was normal profit -- 30% pre-tax!"
> Gene Amdahl interview in April-June 1997, IEEE Design and Test of Computers: "The company decided not to build it because it would have destroyed the pricing structures. In the first place, it would have forced them to make higher-end machines. But with IBM's pricing structure, the market disappeared by the time performance got to a certain level. Any machine above that in performance or price could only lose money."
> In his autobiography, Father, Son, & Co., Tom Watson, Jr., writes about the Model 90 series in competition with CDC and his decision to cancel their sales (Bantam Books, 1990, page 384): "Finally my business sense overcame my pride and I belatedly figured out that we couldn't compete with Control Data for the same reason that General Motors can't compete with Ferrari in building two-hundred-mile-an-hour sports cars. Supercomputers had become so highly specialized that even if we came up with a design equal to theirs, it would never fit in with the rest of our product line, our style of selling, our volume and profit targets, and so on." He goes on to say that his "temper was partly to blame for IBM's erratic behavior in the supercomputer market".
"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 to 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.
There's a dead comment in this thread by the fabled Don Hopkins, and the only reason I can imagine is that he commented, factually but negatively, on Elon Musk. Shameful comment-killing, just shameful.
I believe a lot of people on HN consider trans people rights something controversial and worth censoring.
As for Elon, I will call the website Twitter, because if he can deadname his daughter, I can deadname his companies as well.
After the acquisition of Twitter, a large number of talented people walked away, a lot because of his attitude towards work-life balance, and, I assume, later, as his darkest side became more and more public (culminating in Trump's inauguration Dr. Strangelove event), a lot of the remaining talent left for healthier pastures. That period was full of outages and data loss.
On @DonHopkins, I love his "FORTH ?KNOW IF HONK ELSE FORTH LEARN THEN"
Lynn Conway is one of those ACS inventors who deserves mention. In 1965 she invented generalized dynamic instruction scheduling, enabling multiple instructions to be issued out of order in a single clock cycle -- a foundational advance in superscalar architecture. IBM fired her in 1968 for transitioning. It took the company 52 years to apologize.
The business consequence wasn't merely losing a talented employee. IBM threw away the future contributions of someone who had already demonstrated an extraordinary ability to solve fundamental architectural problems. She subsequently helped launch the Mead-Conway VLSI design revolution at Xerox PARC, making chip design accessible to a much broader community. IBM's bigotry drove that talent, and the opportunity to cultivate her next breakthroughs, out of the company.
We can't put a dollar figure on that loss, or assume retaining her would have saved ACS. But growing System/360 profits don't establish that IBM had "little to worry about." They show how easily a lucrative existing business can conceal the opportunity cost of throwing away exceptional talent. Maybe IBM thought they had the luxury of affording prejudice and bigotry, but it wasn't a sound business judgment.
Perhaps IBM's treatment of Conway supplies another answer to Watson's question. A vast organization can have exceptional talent and still squander it. Conway's firing came after the CDC 6600, but dismissing a pioneering computer architect for transitioning hardly suggests that IBM's problem was a shortage of resources. Sometimes the obstacle between your engineers and the future is your own management's bigotry.
I wonder how much talent Elon Musk has driven away -- trans employees, people with trans family and friends, and anyone repelled by his public humiliation, deadnaming, and misgendering of his own daughter. How many breakthroughs will happen elsewhere because their inventors wanted nothing to do with him? Those losses won't appear as a line item on a balance sheet either.
An interesting connection: Seymour Cray's grandson Andrew Cray was a trans man and LGBTQ healthcare advocate. He married Sarah McBride in 2014, four days before he died of cancer. McBride later became the first openly trans person elected to the US Congress.
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, with 60-bit words and no character addressability, just ludicrously fast (and cool looking). The central processor was augmented by 12 peripheral processors that offloaded IO and other tasks from the CPU (not sure IBM did that, but this - channel processors and channel programs - is a pattern that was common on IBM mainframes at least after the 360).
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.
Excuse me? No character addressability? The scientific machines IBM was selling in 1963, the 704x/709x, were 36-bit-word-addressible. The 6600 was definitely similar to those, in many ways. And you didn't need character addressibility for business applications, there were Cobol compilers for those machines. The stranger feature of the 6600 was the division between the central processor and the peripheral processors; if the 360 had been designed that way, much of the operating system would have been running in the channels, or in the smaller computers then used for offline punchcard/printer support.
A much greater omission was IBM's refusal to consider time-sharing, until it was too late, and then they made a total mess of it with TSS/360. (The 360/67 was a good machine, I have fond memories of it, but it needed a different OS, Michigan Terminal System in our case.) It took IBM a long time to understand the need for interactive computing.
The IBM 704, 7090 were computers targeted at the science market, being (some of?) the first with floating point hardware. Their “business” counterparts would be the 705, 1401 and did decimal math and string processing. You could run business apps on both, but manipulating strings in them is a chore because you either pack a character as a word or you need pointers within pointers. With 36-bit words, at least, you can have a character pointer turn into an address by two bitshifts.
I don’t remember much about time sharing being a thing at that time - batch processing made sense in both kinds of applications.
Oh, and there was a Cobol compiler for the 6600. (Wirth's first Pascal implementation was also for the 6600, as I recall.) My point is that the central processor architecture of the 6600, apart from the large word size, was entirely consistent with the way that scientific computers from IBM, Univac, Philco, General Electric, and other manufacturers were designed.
As for time-sharing,IBM explicitly ruled it out as a design objective for OS/360. Then MIT went shopping for a partner for Multics. IBM had nothing of interest for them, but GE agreed to design a virtual memory version of their 635, the 645. Suddenly, IBM realized that they were going to lose a market, so they rapidly added memory mapping to the 360/65, producing the Model 67. They also announced Time Sharing System/360, but the early versions were unusable (20 minutes to log in, for example), so a few folks at the University of Michigan whipped up an interim solution, the Michigan Terminal System, which worked fine, and was in service at various places from 1968 to the 1990s.
Although IBM produced various time-sharing systems, including Call/360, APL\360, the Time Sharing Option, and VM/CMS, they never really understood it, which is why a few underfunded folks at a university could produce something better than what they could produce with a professionally-managed team.
By contrast, DEC did get it in that era, which is why the PDP-10 did so well in university computer science departments.
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.
"population count" is often associated with hamming distance with uses in information theory, coding theory, and cryptography. There is another use, which I think is what it was really used for - cosine similarity.
The usual definition for two vectors A and B is A.B = |A||B|cos ø. If A and B are binary it becomes, A and B = popcnt(A)popcnt(B)cos ø. The similarity measure is how close cos ø is to 1.
Using modern vocabulary, with a message and a set of search criteria using a word embedding on the message, calculate the similarity to each search using, cos ø = (A and B)/(popcnt A * popcnt B). This is only be vectorizable when there is an intrinsic popcnt instruction. Results that have > 0 values for cos ø mean there is some similarity.
So, to capture, (re)scan and flag all messages that contain certain keywords, design a system to generate a KEYSCORE. When eXtended to reduce false positives, build a follow on system called XKEYSCORE.
The last paragraph is pure speculation, but I think it has merit. Worth a try on your own data?
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 implement either 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). When auto-update is available, 2-component indexed addressing without index scaling is sufficient (where the 2 components may be chosen between base + index register and base + 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).
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.
At least for a couple of years it was a massive success. If they had not done the PC somebody else would have become the PC I think so they were damned if they did and damned if they did not.
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.
The college I was at in the late 70s had a CDC 6600 which I learned FORTRAN. With around 100+ sold, I wonder if that was donated to the school from a company that upgraded their system ? While still at school it was replaced by a CDC 7600.
To me, the system ran very well.
Sad to see all those computer companies disappear over the years, I think there may be only 3 or 4 left making big iron.
I might have gone to the same college, in the 80s. I was a TA helping students punch FORTRAN on cards - already pretty obsolescent.
One thing about the CDC - it had perhaps the worst command interface I've run into. Data files were modeled as tapes, and you had to keep rewinding them.
Compiling a program appended to the object file, but running ran the start of the file, so you needed to rewind between, lest you run an old version. Much time lost trying to figure out why changes were ineffective.
FORTRAN variables had 8 significant characters, but the linker had only seven, so it was possible to get unintentional aliases.
University of Arizona? I remember their antediluvian Cyber in 1984 and helping my roommates punch Fortran on cards. I at least got to use a VAX 11/750.
Excerpts from Mark Smotherman's ACS site [1] ...
> To achieve a profit for the ACS program, Amdahl asked IBM management to approve three ACS/360 models: the high-performance design, a 1/3 performance version, and a 1/9 performance version. He felt that these performance goals would be a good fit with the System 360 marketing plans. He remembers that IBM Corporate Marketing evaluated the targets and reported: "1) the supercomputer alone was a loss leader! 2) the supercomputer plus the 1/3 performance computer was break-even! And 3) the supercomputer plus both the 1/3 performance computer and the 1/9 performance computer was normal profit -- 30% pre-tax!"
> Gene Amdahl interview in April-June 1997, IEEE Design and Test of Computers: "The company decided not to build it because it would have destroyed the pricing structures. In the first place, it would have forced them to make higher-end machines. But with IBM's pricing structure, the market disappeared by the time performance got to a certain level. Any machine above that in performance or price could only lose money."
> In his autobiography, Father, Son, & Co., Tom Watson, Jr., writes about the Model 90 series in competition with CDC and his decision to cancel their sales (Bantam Books, 1990, page 384): "Finally my business sense overcame my pride and I belatedly figured out that we couldn't compete with Control Data for the same reason that General Motors can't compete with Ferrari in building two-hundred-mile-an-hour sports cars. Supercomputers had become so highly specialized that even if we came up with a design equal to theirs, it would never fit in with the rest of our product line, our style of selling, our volume and profit targets, and so on." He goes on to say that his "temper was partly to blame for IBM's erratic behavior in the supercomputer market".
[1] https://people.computing.clemson.edu/~mark/acs_end.html
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 to 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.
Firstly, it's "God", not "Cray". And secondly, yeah, he had some great quotes.
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.
There's a dead comment in this thread by the fabled Don Hopkins, and the only reason I can imagine is that he commented, factually but negatively, on Elon Musk. Shameful comment-killing, just shameful.
I believe a lot of people on HN consider trans people rights something controversial and worth censoring.
As for Elon, I will call the website Twitter, because if he can deadname his daughter, I can deadname his companies as well.
After the acquisition of Twitter, a large number of talented people walked away, a lot because of his attitude towards work-life balance, and, I assume, later, as his darkest side became more and more public (culminating in Trump's inauguration Dr. Strangelove event), a lot of the remaining talent left for healthier pastures. That period was full of outages and data loss.
On @DonHopkins, I love his "FORTH ?KNOW IF HONK ELSE FORTH LEARN THEN"
Lynn Conway is one of those ACS inventors who deserves mention. In 1965 she invented generalized dynamic instruction scheduling, enabling multiple instructions to be issued out of order in a single clock cycle -- a foundational advance in superscalar architecture. IBM fired her in 1968 for transitioning. It took the company 52 years to apologize.
The business consequence wasn't merely losing a talented employee. IBM threw away the future contributions of someone who had already demonstrated an extraordinary ability to solve fundamental architectural problems. She subsequently helped launch the Mead-Conway VLSI design revolution at Xerox PARC, making chip design accessible to a much broader community. IBM's bigotry drove that talent, and the opportunity to cultivate her next breakthroughs, out of the company.
We can't put a dollar figure on that loss, or assume retaining her would have saved ACS. But growing System/360 profits don't establish that IBM had "little to worry about." They show how easily a lucrative existing business can conceal the opportunity cost of throwing away exceptional talent. Maybe IBM thought they had the luxury of affording prejudice and bigotry, but it wasn't a sound business judgment.
Perhaps IBM's treatment of Conway supplies another answer to Watson's question. A vast organization can have exceptional talent and still squander it. Conway's firing came after the CDC 6600, but dismissing a pioneering computer architect for transitioning hardly suggests that IBM's problem was a shortage of resources. Sometimes the obstacle between your engineers and the future is your own management's bigotry.
I wonder how much talent Elon Musk has driven away -- trans employees, people with trans family and friends, and anyone repelled by his public humiliation, deadnaming, and misgendering of his own daughter. How many breakthroughs will happen elsewhere because their inventors wanted nothing to do with him? Those losses won't appear as a line item on a balance sheet either.
An interesting connection: Seymour Cray's grandson Andrew Cray was a trans man and LGBTQ healthcare advocate. He married Sarah McBride in 2014, four days before he died of cancer. McBride later became the first openly trans person elected to the US Congress.
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, with 60-bit words and no character addressability, just ludicrously fast (and cool looking). The central processor was augmented by 12 peripheral processors that offloaded IO and other tasks from the CPU (not sure IBM did that, but this - channel processors and channel programs - is a pattern that was common on IBM mainframes at least after the 360).
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.
Excuse me? No character addressability? The scientific machines IBM was selling in 1963, the 704x/709x, were 36-bit-word-addressible. The 6600 was definitely similar to those, in many ways. And you didn't need character addressibility for business applications, there were Cobol compilers for those machines. The stranger feature of the 6600 was the division between the central processor and the peripheral processors; if the 360 had been designed that way, much of the operating system would have been running in the channels, or in the smaller computers then used for offline punchcard/printer support.
A much greater omission was IBM's refusal to consider time-sharing, until it was too late, and then they made a total mess of it with TSS/360. (The 360/67 was a good machine, I have fond memories of it, but it needed a different OS, Michigan Terminal System in our case.) It took IBM a long time to understand the need for interactive computing.
The IBM 704, 7090 were computers targeted at the science market, being (some of?) the first with floating point hardware. Their “business” counterparts would be the 705, 1401 and did decimal math and string processing. You could run business apps on both, but manipulating strings in them is a chore because you either pack a character as a word or you need pointers within pointers. With 36-bit words, at least, you can have a character pointer turn into an address by two bitshifts.
I don’t remember much about time sharing being a thing at that time - batch processing made sense in both kinds of applications.
Oh, and there was a Cobol compiler for the 6600. (Wirth's first Pascal implementation was also for the 6600, as I recall.) My point is that the central processor architecture of the 6600, apart from the large word size, was entirely consistent with the way that scientific computers from IBM, Univac, Philco, General Electric, and other manufacturers were designed.
As for time-sharing,IBM explicitly ruled it out as a design objective for OS/360. Then MIT went shopping for a partner for Multics. IBM had nothing of interest for them, but GE agreed to design a virtual memory version of their 635, the 645. Suddenly, IBM realized that they were going to lose a market, so they rapidly added memory mapping to the 360/65, producing the Model 67. They also announced Time Sharing System/360, but the early versions were unusable (20 minutes to log in, for example), so a few folks at the University of Michigan whipped up an interim solution, the Michigan Terminal System, which worked fine, and was in service at various places from 1968 to the 1990s.
Although IBM produced various time-sharing systems, including Call/360, APL\360, the Time Sharing Option, and VM/CMS, they never really understood it, which is why a few underfunded folks at a university could produce something better than what they could produce with a professionally-managed team.
By contrast, DEC did get it in that era, which is why the PDP-10 did so well in university computer science departments.
The Mythical Man-Month was only published in 1975.
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.
"population count" is often associated with hamming distance with uses in information theory, coding theory, and cryptography. There is another use, which I think is what it was really used for - cosine similarity.
The usual definition for two vectors A and B is A.B = |A||B|cos ø. If A and B are binary it becomes, A and B = popcnt(A)popcnt(B)cos ø. The similarity measure is how close cos ø is to 1.
Using modern vocabulary, with a message and a set of search criteria using a word embedding on the message, calculate the similarity to each search using, cos ø = (A and B)/(popcnt A * popcnt B). This is only be vectorizable when there is an intrinsic popcnt instruction. Results that have > 0 values for cos ø mean there is some similarity.
So, to capture, (re)scan and flag all messages that contain certain keywords, design a system to generate a KEYSCORE. When eXtended to reduce false positives, build a follow on system called XKEYSCORE.
The last paragraph is pure speculation, but I think it has merit. Worth a try on your own data?
> "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 implement either 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). When auto-update is available, 2-component indexed addressing without index scaling is sufficient (where the 2 components may be chosen between base + index register and base + 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).
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.
At least for a couple of years it was a massive success. If they had not done the PC somebody else would have become the PC I think so they were damned if they did and damned if they did not.
Free rein*
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.
[flagged]
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.
The college I was at in the late 70s had a CDC 6600 which I learned FORTRAN. With around 100+ sold, I wonder if that was donated to the school from a company that upgraded their system ? While still at school it was replaced by a CDC 7600.
To me, the system ran very well.
Sad to see all those computer companies disappear over the years, I think there may be only 3 or 4 left making big iron.
I might have gone to the same college, in the 80s. I was a TA helping students punch FORTRAN on cards - already pretty obsolescent.
One thing about the CDC - it had perhaps the worst command interface I've run into. Data files were modeled as tapes, and you had to keep rewinding them.
Compiling a program appended to the object file, but running ran the start of the file, so you needed to rewind between, lest you run an old version. Much time lost trying to figure out why changes were ineffective.
FORTRAN variables had 8 significant characters, but the linker had only seven, so it was possible to get unintentional aliases.
As a grad student, I got to use a VAX.
University of Arizona? I remember their antediluvian Cyber in 1984 and helping my roommates punch Fortran on cards. I at least got to use a VAX 11/750.