What made the 1960s CDC6600 supercomputer fast?
cpldcpu.wordpress.com
cpldcpu.wordpress.com
However, they had 60 bit words and no way to address data directly within a word. By convention, characters were six bits long, stuffed in 10 characters to a word. So while this machine was incredibly fast for its time for numerical calculation, it was painful to do text manipulation. You had to pack and shift characters into words, and unshift and unpack. You could do interesting things with great cleverness, but it took a lot of work to do simple things.
Thanks for the trip down memory lane.
This expands on the text processing issues:
https://www.museumwaalsdorp.nl/en/history/computerhistory-ba...
"There was no byte addressability. If you wanted to store multiple characters in a 60-bit word, you had to shift and mask. Typically, a six-bit character set was used, which meant no lower-case. These systems were meant to be (super)computing engines, not text processors! To signal the end of a text string, e.g. a sentence, two different coding techniques were invented. The so-called 64 character set was the CDC-default. A line end comprised of two (or more) null-“bytes” at the end of a word followed by a full zero word. The 63 character set, quite popular in the Netherlands and the University of Austin, Texas, signalled the line termination by two (or more) null-“bytes” at the end of a 60-bit word.
The Michigan State University (MSU) invented a 12-bit character set, which was basically 7-bit ASCII format with five wasted bits per character. Other sites used special shift/unshift characters in a 6-bit character set to achieve upper/lower case."
The most interesting architectural feature was that all I/O was relegated to peripheral processors so that the main CPU could run unimpeded.
10 PRINT "YOUR MOMMA" came back as 10 PRINT "KOUR IOMMA"
CDC went all in on this. Their large computers had ‘peripheral processors’ (for the CDC6600, based on the CDC160) that essentially ran the OS, leaving the main processor free for what it was good at.
The Wii and WiiU run most of the "OS" on an external ARM core "Starlet"/"Starbuck". All I/O, network access, encryption for SSL, booting the main cores, the USB stack, etc. is on that ARM core, not the main PowerPC cores so those can be dedicated to running "game code".
The Cell in the PS3 is a SPI slave that gets booted by an external processor.
The PS4 is the same way, and that external core holds most of the filesystem (how game updates happen with the console "off").
And then most SoCs (including most AMD and Intel chips) boot system management cores (ME/PSP/etc.) that then is responsible for initializing the rest of the core complexes on the chip. Pretty much every ARM SoC sold these days will talk about how they have a CortexM3 in addition to they CortexA cores; that's what it's for. SiFive's Linux capable chip has one of their E series cores in addition to their U series cores for the same purpose on the RISC-V side of things.
Usually the advertised-on-the-datasheet M cores are available for user code and you'll get a virtual serial port or some shared memory to go between them and the big core. I don't doubt that there are additional hidden cores taking care of internal power management, early boot etc.
At least, this is how it is on the STM32MP1 and the TI Sitara AM5 socs.
http://www.lysator.liu.se/hackdict/split2/pascal.html
> Pascal n. An Algol-descended language designed by Niklaus Wirth on the CDC 6600
The CDC 6600 was used as the student mainframe for George Mason University (GMU) in Northern Virginia in the 1980s. For engineering classes (e.g., electronics engineering) the 6600 was still excellent; it could run simulations far faster than many systems that had been built later, and it was certainly faster at that task than the personal computers of that early time (Apple //es or the original IBM PC). People also used the 6600 for writing text, compiling, etc. The computer was a terrible match for that, but it was fast enough that the mismatch of capabilities still made it useful for the purpose.
Oh, and a quick aside: Today's computers are much faster, but much of that speed is taken away by software that's more functional and less efficient. I once shared an IBM PC (4.77MHz) among 16 users. If your computer software is generally efficient, and you're willing to reduce what it does, a single computer can serve a remarkably large number of users. Nobody worried about font selection, for example. So it was with the 6600; it could serve many users, if carefully managed.
Now for the story, which I can't confirm but I believe to be true. At the time GMU was a scrappy new local university. It was in a great location (Northern Virginia, which was expanding rapidly). However, although it was a state university, it had little support from the capital (power is divided among counties, and the rural counties easily outvoted Northern Virginia).
GMU's president, President Johnson, had much bigger plans for GMU. So Johnson arranged for a hand-me-down supercomputer (the 6600) for nearly nothing. This computer was considered obsolete by then, and it was terrible at text processing. Even so, it was still fast enough to be useful, and more importantly, it was a supercomputer, even though it had been obsoleted. My understanding is that Johnson sold the pitch of "GMU has a supercomputer now" to all the local businesses, asking them to help fund GMU & cooperate in various ways. The local businesses did, greatly so.
I suspect most of the businesses knew the "supercomputer" wasn't a current speed champion, and as I far as I know no lies were told. But that wasn't the point. The pitch "we have a supercomputer" was good enough to make it much easier for some people in various businesses to justify (to their cohorts) donating to GMU & working with GMU. Many businesses in Northern Virginia wanted GMU to succeed, because they would greatly benefit long-term with a good university in their backyard... they just needed a good-enough story to win over those who might veto it internally. This "we have a supercomputer" pitch (and other things) worked. Once GMU got "real" money, they invested it, e.g., they upgraded (and kept upgrading) to better equipment. GMU grew quickly into quite a powerhouse; it's now the largest state university in Virginia. One of GMU's distinctives is the huge number of connections it has to local businesses and government organizations. Originally this was because GMU couldn't rely on state funding, but the need to interconnect with local organizations led over time to an emphasis on applying academic knowledge to real-world problems. It's interesting to see how problems + scrappiness can lead to long-term cultures within an organization. Johnson passed away in 2017 ( https://www2.gmu.edu/news/427091 ), but his legacy continues.
Those in organizations who delved into the details found that yes, it's a supercomputer. It's a really obsolete one. But it is more capable than the PCs. More importantly, it showed that the university was very resourceful, and imagine what it could do if it got real money! In addition, having a good university next door was attractive, but only if there was a plausible path to get there.
But that was a complicated story to tell, so this whole thing provided a simpler story: "They have a supercomputer". All big organizations have bureaucratic inertia, and this simpler story was useful for people who didn't want to go into the details but might veto something.
My wife calls this "theater", and that's a good word. In this case, it was theater that helped counter bureaucratic inertia.
GMU took the few resources it had, and did a lot with them. People saw that, gave them real resources, and GMU quick grew into a powerhouse. I think that's an interesting story, and the 6600 played a part in it.
Hell, at the time, given the choice between a Cray and two 6600s, for students I'd lean two 6600s.
So, did Dijkstra invent the null-terminated string? (What else links Austin and the Netherlands in computing at that time?)
Seems plausible to me. Or maybe some grad student working with him, and noone really cared who "invented it", since it seemed like such an obvious idea....
https://www.museumwaalsdorp.nl/en/history/comphistory/comput... says:
> A Control Data 6400 system was installed in May 1974 ...
> The Laboratory, like all other computer centres in the Netherlands, had opted for the so-called 63 character set. Control Data only tested systems with the 64 character set in America. Unsatisfactory code or code from “new” programmers yielded one or more errors with almost every new release, which we corrected at the TNO Physics Laboratory and made public with a lot of misgivings through the Problem Reporting System mechanism (PSR). Every two weeks a set of microfiches with all complaints and solutions collected worldwide was sent to all computer centres by Control Data. At every release level, it was exciting whether the errors we found were the first to report or that our colleague from the University of Arizona was going to blame
That gives a mismatch between "University of Austin, Texas" and "University of Arizona".
https://en.wikipedia.org/wiki/Edsger_W._Dijkstra says he joined the University of Texas at Austin in 1984. In the 1970s he lived in the Netherlands.
https://en.wikipedia.org/wiki/Null-terminated_string says that the PDP-11 in 1970 had NUL-terminated strings ("Null-terminated strings were produced by the .ASCIZ directive of the PDP-11 assembly languages and the ASCIZ directive of the MACRO-10 macro assembly language for the PDP-10.")
This was when Dijkstra was at the Eindhoven University of Technology.
Therefore, whatever is described at the link cannot be used to conclude that Dijkstra had anything to do with nul-terminated strings.
”Niklaus told a terrible story about CDC-software. With 10 six-bit characters (from an alphabet of 63) packed into one word, CDC used the 64th configuration to indicate "end of line"; when for compatibility reasons a 64th character had to be added, they invented the following convention for indicating the end of a line: two successive colons on positions 10k+8 and 10k+9 —a fixed position in the word!— is interpreted as "end of line". The argument was clearly that colons hardly ever occur, let alone two successive ones! Tony was severely shocked "How can one build reliable programs on top of a system with consciously built-in unreliability?". I shared his horror: he suggested that at the next International Conference on Software Reliability a speaker should just mention the above dirty trick and then let the audience think about its consequences for the rest of his time slice!”
I don’t think that
It could be related to the fact that UT Austin wrote and maintained their own OS (UT-2D) for the CDC/CYBER architecture, and maintained it well in to the late 1990's/early 2000's.
Another way to think of it is that it was fully emoji-and-variant-selector-ready way ahead of its time.
"It seems like Mr. Watson has answered his own question."
The different weights also make it look like a mechanical typewriter rather than an electric one, which would be an odd choice for the office of TJW.
> Let me know if you find similar devices.
The Rohm high-frequency BJTs look promising: 2SC3838K is the fastest (fT wise), but there are several others (see page C28 of Rohm's 2019 catalog). I only checked the datasheet for the one, but it's got a very nice Figure 10, showing that it'll probably switch fastest around 20mA collector current, and should be about 3x faster there than the MMBTH10L at 4mA.
That's how Cray built supercomputers after the CDC6600/7600.
ECL was amazing for its time, but I'm honestly more impressed by modern PC/phone electronics. PCBs and chip designs are mass-produced commodity products clocked at microwave frequencies - sometimes with battery power.
This is incredibly impressive compared to the state of the art in the 60s and 70s. And it's taken for granted as an everyday thing.
I took a computer science course at Dalhousie University in 1970, used a CDC 6400. My professor was obsessed with pseudo-random numbers, the 60-bit word size was a godsend.
In 1974 I learned CDC6600 assembly language in grad school. In comparison to IBM360 assembly language programming I had previously done, the CDC 6600 was so straightforward. It took perhaps one day to learn all of it. I still have the small book that I learned from, Assembly Language Programming for the Control Data 6000 Series and the Cyber 70 Series by Ralph Grishman.
Addressing: The machine had unusual data layout, it was word, not byte addressable and each word was 60 bits long, not 16 or 32 bits long.
Data Format: Text was stored in six-bit fields, ten per word and so the characters weren't directly addressable. Furthermore, integers were stored in 1's complement, not the more common 2's complement or sign-magnitude format. There was a single 60-bit floating point format (1-bit sign, 11-bit exponent, and 48-bit coefficient).
Speed: Floating point multiplication took 1000ns, but the 6600 could do two floating point multiplies, a floating point add, and an integer add simultaneously if coded carefully.
Memory: The memory of the 6600 was stored in a ferrite core memory and it had a maximum size of 128K words. Later, there were slower, larger memory tiers as options.
I/O: This was handled by peripheral processors that had access to the main memory and could offload data transfers to devices so that the central processing unit didn't have to handle expensive interrupts (expensive because the out-of-order execution of instructions meant that saving and restoring the state of the CPU was relatively time-consuming).
Registers: There were 8 X-registers. These are 60-bit registers that are used as the operands in the assembly language instructions. There are also 8 18-bit A-registers that are used for addressing and an additional 8 18-bit B-registers for use as loop indexes, etc.
Instructions: Opcodes are always 6 bits, there are only 71 instructions (one of the 64 possibilities in the 6-bit op code is further divided into 8 instructions). The instructions were simple:
IX4 X5+X6 ; Integer sum of X5 plus X6 goes into X4
This was all a lot less to understand than the intricacies of the IBM360 principles of operation. The IBM360 of the time had instructions like TRANSLATE-AND-TEST or the SHIFT-AND-ROUND-DECIMAL. Here for example are the first four paragraphs explaining the TRANSLATE-AND-TEST instruction from the IBM 360 Principles of Operation:
> The eight-bit bytes of the first operand are used as arguments to reference the list designated by the second operand address. Each eight-bit function byte thus selected from the list is used to determine the continuation of the operation. When the function byte is a zero, the operation proceeds by fetching and translating the next argument byte. When the function byte is nonzero, the operation is completed by inserting the related argument address in general register 1, and by inserting the function byte in general register 2.
> The bytes of the first operand are selected one by one for translation, proceeding from left to right. The first operand remains unchanged in storage. Fetching of the function byte from the list is performed as in TRANSLATE. The function byte retrieved from the list is inspected for the all-zero combination.
> When the function byte is zero, the operation proceeds with the next operand byte. When the first operand field is exhausted before a nonzero function byte is encountered, the operation is completed by setting the condition code to O. The contents of general register 1 and 2 remain unchanged.
> When the function byte is nonzero, the related argument address is inserted in the low-order 24 bits of register 1. This address points to the argument last translated. The high-order eight bits of register 1 remain unchanged. The function byte is inserted in the low-order eight bits of general register 2. Bits 0-23 of rcgister 2 remain unchanged. The condition code is set to 1 when the one or more argument bytes have not been translated. The condition code is set to 2 if the last function byte is nonzero.
> ... [There's a lot more]
For an insight into that great man’s life, I highly recommend reading The Supermen: The Story of Seymour Cray and the Technical Wizards Behind the Supercomputer by Charles J. Murray. I remember reading it back when I was in high-school so it’s more than twenty years old by now, but it’s still an amazing account of how those amazing people built those stunning machines.
To give you an idea of when this was, I think they were just finishing the final tests of serial #5 of the Cray-1. They were very proud of the cooling system and invited us to touch the panels.
A guy went out to eat in a New York restaurant. A couple came in, a pale white dude accompanied by the most beautiful black woman this guy had seen. They were seated close to him. It was immediately obvious to him that they were getting much better service than him - for instance they got their food almost immediately after ordering, while he was still waiting for his. So he started to heckle them.
Fast forward to a year later. David Bowie has died, and his picture is on the front cover of every magazine. This guy finally realizes who it was he'd been heckling.
We went to dinner and the conversation started around the Buzz at the show: Shell Oil was deploying a 500 megabit network in the Dallas Area. Like a half hour and a dozen topics later, Al just blurts out “they need that bandwidth to ship around the imaging data they collect from their surveys”. It came across like he had two brains, one that was engaged in the conversation, and the other figuring out what in the hell are these guys doing with all that bandwidth. Which was a lot in the day of 14.4k modems and T1 lines. After dinner when we parted ways with Al, our conversation was all about how we thought his brain might work.
https://www.youtube.com/watch?v=8Z9VStbhplQ
The Q&A section is quite interesting. His knowledge of technical details is very impressive and you can feel the tremendous amount of respect that was bestowed on him by the audience.
>1964
That's insane. What's even more insane is that a bit over 20 years later homecomputers reached that frequency. And in the next decade they reached over 100 MHz. - Pure lunacy.
Posted from my 5 GHz homecomputer.
They're topological circuit constructions that work for either family - aren't they?
MOS is just hard. It's hard to fabricate, it's hard to design (i.e. you need computers to make computers!), it's hard to scale. It required new chemistries be invented and new circuit design techniques to manage the (really tiny!) components. So for a long time you could have a big circuit in discrete bipolar components which ran fast or a tiny one in MOS which was slow.
But MOS was tiny and MOS was cheap. So by the early 90's it had caught up in speed with all but the fastest discrete technologies (GaAs was "right around the corner" for like two decades as it kept getting lapped by routine process shrinks -- now no one remembers it) and the market abandoned everything else.
I think the important point is that "MOS scales". All the bipolar technologies never had anything like Dennard scaling, which was the backbone of Moores Law.
CDC-6600, 1964: 60-bit processor @ 10 MHz, 2 MIPS, 1 MFLOPS
CDC-7600, 1967: 60-bit processor @ 36 MHz, 15 MIPS, 36 MFLOPS
Cray-1, 1975: 64-bit processor @ 80 MHz, 80 MIPS, 160 MFLOPS
I think this means that if a corresponding development in video coprocessors had been taking place (there wasn't really a recognized need for them back then, as far as I can tell), the CDC-6600 could have been running Wolfenstein 3D decently well in 1964, 28 years before the launch in 1992.
And the CDC-7600 could have been running DOOM decently well in 1967, 26 years before the launch in 1993.
But it built on the history of “display processors” already in use: http://www.cap-lore.com/Hardware/Wheel.html
I had thought that computers of the time didn't have enough RAM for a framebuffer, but evidently the CDC6600 did, with what we would call 982 kilobytes today.
I mean.. I did see https://www.ftdichip.com/EVE/EVEApplications.htm .. but, in reality?
Are you based out of Taiwan?
You could imagine putting something like a 320×200 CGA on a CDC 6600, taking what we would now call 16000 bytes of memory, at a cost of around US$40 000 in 1965 (https://jcmit.net/memoryprice.htm says). But it seems like it would be hard to justify that as a good alternative to adding those 16000 bytes to the machine's main memory, supplying an extra 1.6% of its address space with storage and allowing it to tackle problems that were, say, 5% larger.
(There may also have been a question of memory speed. The memory cited above that cost US$2.50 a bit was core, and maybe it had a 300 ns cycle time; a 320×200 display at 50 Hz minimally requires a 312.5 ns dot clock, and probably quite a bit faster than that because of the blanking intervals, so you might have needed two to four memory banks just to satisfy the RAMDAC's hunger for pixels. Of course they wouldn't have called it a "RAMDAC" or "dot clock" at the time.)
"On the shoulder of giants" is an old and very true statement.
“Wolfenstein 3D on my basement CDC 6600”
The CDCs still had a good run. This line was originally released in 1964. It started at 10MHz, but that was 60 bit words, and special floating-point systems. IIRC floating-point multiplies were only one clock cycle; if that's correct, it took 100 nanoseconds.
The Apple II came out in 1977, 1MHz, 8 bit CPU and no floating-point circuits. You had to use many cycles to do any floating point, and typically you only used 32-bit floating point (because it was painful enough there). A single 32-bit floating point multiply took 3-4 milliseconds according to: https://books.google.com/books?id=xJnfBwAAQBAJ&pg=PA26&lpg=P...
The original IBM PC came out in 1981. Its clock was 4.77 MHz. But again, that was misleading. Internally the 8086 was a 16-bit CPU but its memory I/O was only 8 bits wide. It didn't normally come with a floating-point processor. There was one, the 8087, and I think the original IBM PC had a socket for it, but it cost big $$$ and the 8087 wasn't actually available for purchase until ~6 months after the PC's release. That one could go 4-10MHz. If you bought a coprocessor, you were finally getting to somewhat similar speeds for numerical calculations... but that was 16+ years later.
Did you mean 8088 here?
A product generation later, Intel changed what this meant to indicate whether or not the CPU had an on-chip FPU.
Those were the days you looked at the TRW multipliers (packed in 64+ pin DIPs) advertised in trade magazines like auto buffs might at V8 engines ...
Intel sold their own 8087, until it was digested into the vast expanses of CPU chips opened by scaling.
The type on the twin CRTs of the console is very interesting. The cover of the book shows a sample of it and the slight imprecisions of the beam deflection give it a whimsical quality, as if the fastest computer of its time used Comic Sans to communicate with its operator.
Whoever picked 60 bits (Cray?) was almost certainly thinking in octal, not hex. 60 bits is multiple of 3, it fits in 20 octal digits, and it holds 10 characters. Most importantly, a 60-bit floating point number is precise enough for just about any calculation.