https://chipsandcheese.com/2024/04/01/inside-control-data-corporations-cdc-6600/
Not sure who follows this web site, it has quite some interesting
articles, usually on newer processor designs. Here's one that's
maybe not quite so serious, but amusing and informative at the
same time:
https://chipsandcheese.com/2024/04/01/inside-control-data-corporations-cdc-6600/
"Frontend: Branch Prediction There is no branch prediction."
On Sat, 20 Jul 2024 08:35:20 -0000 (UTC), Thomas Koenig wrote:
https://chipsandcheese.com/2024/04/01/inside-control-data-corporations-cdc-6600/
Note the date. ;)
That bit at the end, about how the world would need maybe only ten computers, because the 6600 is so powerful, and out-of-order machines
running at 5 GHz would never be needed, of course, is the funny part...
On Sun, 21 Jul 2024 07:35:55 -0600, John Savard wrote:I
That bit at the end, about how the world would need maybe only ten
computers, because the 6600 is so powerful, and out-of-order machines
running at 5 GHz would never be needed, of course, is the funny part...
Also a dig at IBM, from whose (early) boss (Watson Sr?) the quote about
the world only needing ten computers is supposed to have originated.
The 6600 (and its siblings) also popularized the term “supercomputer”. When people at the time thought “computer”, they thought “IBM”. But here
was a machine that was so far ahead in performance, it left IBM (and everybody else) in the dust.
IBM CEO said something to the effect:: How can a team of 24 people,
including the janitor, beat IBM ??
On Sun, 21 Jul 2024 22:21:41 +0000, MitchAlsup1 wrote:
IBM CEO said something to the effect:: How can a team of 24 people,
including the janitor, beat IBM ??
From Watson’s memo:
Last week Control Data had a press conference during which they
officially announced their 6600 system. I understand that in the
laboratory developing this system there are only 34 people,
including the janitor. Of these, 14 are engineers and 4 are
programmers, and only one person has a Ph.D., a relatively junior
programmer. Contrasting this modest effort with our own vast
development activities, I fail to understand why we have lost our
industry leadership position by letting someone else offer the
world’s most powerful computer.
On 2024-07-22 3:05, Lawrence D'Oliveiro wrote:
On Sun, 21 Jul 2024 22:21:41 +0000, MitchAlsup1 wrote:
IBM CEO said something to the effect:: How can a team of 24 people,
including the janitor, beat IBM ??
From Watson’s memo:
Last week Control Data had a press conference during which they
officially announced their 6600 system. I understand that in
the laboratory developing this system there are only 34 people,
including the janitor. Of these, 14 are engineers and 4 are
programmers, and only one person has a Ph.D., a relatively
junior programmer. Contrasting this modest effort with our own vast
development activities, I fail to understand why we have lost
our industry leadership position by letting someone else offer the
world’s most powerful computer.
Per Wikipedia, Cray's reply was sardonic: "It seems like Mr. Watson
has answered his own question."
On Mon, 22 Jul 2024 10:43:44 +0300
Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
On 2024-07-22 3:05, Lawrence D'Oliveiro wrote:
On Sun, 21 Jul 2024 22:21:41 +0000, MitchAlsup1 wrote:
IBM CEO said something to the effect:: How can a team of 24 people,
including the janitor, beat IBM ??
From Watson’s memo:
Last week Control Data had a press conference during which they
officially announced their 6600 system. I understand that in
the laboratory developing this system there are only 34 people,
including the janitor. Of these, 14 are engineers and 4 are
programmers, and only one person has a Ph.D., a relatively
junior programmer. Contrasting this modest effort with our own vast
development activities, I fail to understand why we have lost
our industry leadership position by letting someone else offer the
world’s most powerful computer.
Per Wikipedia, Cray's reply was sardonic: "It seems like Mr. Watson
has answered his own question."
At the end, the influence of 6600 on computers we use today is close to
zero. On the other hand, influence of S/360 Model 85 is massive and
influence of S/360 Model 91 is significant, although far less than the
credit it is often given in popular articles.
Back at their time 6600 was huge success and both Model 85 and Model 91
were probably considered failures.
On Mon, 22 Jul 2024 10:43:44 +0300
Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
On 2024-07-22 3:05, Lawrence D'Oliveiro wrote:
On Sun, 21 Jul 2024 22:21:41 +0000, MitchAlsup1 wrote:
IBM CEO said something to the effect:: How can a team of 24 people,
including the janitor, beat IBM ??
From Watson’s memo:
Last week Control Data had a press conference during which they
officially announced their 6600 system. I understand that in
the laboratory developing this system there are only 34 people,
including the janitor. Of these, 14 are engineers and 4 are
programmers, and only one person has a Ph.D., a relatively
junior programmer. Contrasting this modest effort with our own vast
development activities, I fail to understand why we have lost
our industry leadership position by letting someone else offer the
world’s most powerful computer.
Per Wikipedia, Cray's reply was sardonic: "It seems like Mr. Watson
has answered his own question."
At the end, the influence of 6600 on computers we use today is close to
zero.
On the other hand, influence of S/360 Model 85 is massive and influence of S/360 Model 91 is significant, although far less than the
credit it is often given in popular articles.
Back at their time 6600 was huge success and both Model 85 and Model 91
were probably considered failures.
At the end, the influence of 6600 on computers we use today is close to
zero. On the other hand, influence of S/360 Model 85 is massive and
influence of S/360 Model 91 is significant, although far less than the
credit it is often given in popular articles.
Back at their time 6600 was huge success and both Model 85 and Model 91
were probably considered failures.
On Mon, 22 Jul 2024 10:08:27 +0000, Michael S wrote:
On Mon, 22 Jul 2024 10:43:44 +0300
Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
On 2024-07-22 3:05, Lawrence D'Oliveiro wrote:
On Sun, 21 Jul 2024 22:21:41 +0000, MitchAlsup1 wrote:
IBM CEO said something to the effect:: How can a team of 24
people, including the janitor, beat IBM ??
From Watson’s memo:
Last week Control Data had a press conference during which
they officially announced their 6600 system. I understand that in
the laboratory developing this system there are only 34 people,
including the janitor. Of these, 14 are engineers and 4 are
programmers, and only one person has a Ph.D., a relatively
junior programmer. Contrasting this modest effort with our own
vast development activities, I fail to understand why we have lost
our industry leadership position by letting someone else offer the
world’s most powerful computer.
Per Wikipedia, Cray's reply was sardonic: "It seems like Mr. Watson
has answered his own question."
At the end, the influence of 6600 on computers we use today is
close to zero.
CDC 6600 had a RISC instruction set !!
Michael S <already5chosen@yahoo.com> writes:
At the end, the influence of 6600 on computers we use today is close to >>zero. On the other hand, influence of S/360 Model 85 is massive and >>influence of S/360 Model 91 is significant, although far less than the >>credit it is often given in popular articles.
Yes, all modern computers have virtual memory (which started with
Atlas (and later S/360 Model 67), they have caches, which started with
Titan (and later S/360 Model 85), they have reservation stations
(which started with S/360 Model 91).
However, the main reason why reservation stations won is because
hardware branch prediction outpaced compiler branch prediction since
the early 1990s*, and because the reorder buffer was invented, neither
of which is due to anything done in any S/360 model or the CDC 6600).
Michael S <already5chosen@yahoo.com> writes:
At the end, the influence of 6600 on computers we use today is close to >>zero. On the other hand, influence of S/360 Model 85 is massive and >>influence of S/360 Model 91 is significant, although far less than the >>credit it is often given in popular articles.
Yes, all modern computers have virtual memory (which started with
Atlas (and later S/360 Model 67), they have caches, which started with
Titan (and later S/360 Model 85), they have reservation stations
(which started with S/360 Model 91).
However, the main reason why reservation stations won is because
hardware branch prediction outpaced compiler branch prediction since
the early 1990s*, and because the reorder buffer was invented, neither
of which is due to anything done in any S/360 model or the CDC 6600).
If hardware branch prediction had never been invented or had turned
out to be a dud, maybe we would all be using EPIC architectures that
use scoreboards rather then reservation stations; or maybe the
register interlocks that were used in advanced in-order RISCs (those
that Mitch Alsup calls OoO) and AFAIK in IA-64 implementations were
good enough and one would have done without scoreboard.
[*] More supercomputing-oriented people may claim that it has to do
with the number of in-flight memory accesses, but actually IA-64 shone
on SPEC FP (where in-flight memory accesses are more important than
for SPECint), so it seems that there are ways to get the needed
in-flight memory accesses with in-order execution.
Basically, the hardware would modify the branch opcode in
memory after every branch to track the last two taken/not-taken
states.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
However, the main reason why reservation stations won is because
hardware branch prediction outpaced compiler branch prediction since
the early 1990s*, and because the reorder buffer was invented, neither
of which is due to anything done in any S/360 model or the CDC 6600).
FWIW, The burroughs medium systems had hardware branch
prediction circa 1979. It had some warts, however,
when used in SMP configurations.
Basically, the hardware would modify the branch opcode in
memory after every branch to track the last two taken/not-taken
states.
IA-64 had 2× the number of pins compared to its x86 brethren.
No wonder it could consume more BW.
If hardware branch prediction had never been invented or had turned
out to be a dud, maybe we would all be using EPIC architectures that
use scoreboards rather then reservation stations; or maybe the
CDC 7600 predicted backwards branches to be taken
register interlocks that were used in advanced in-order RISCs (those
that Mitch Alsup calls OoO) and AFAIK in IA-64 implementations were
good enough and one would have done without scoreboard.
Register interlocks is the means to allow GHW to move instructions
around in the pipeline--you just have to obey RAW, WAR, and WAW
hazards.
[*] More supercomputing-oriented people may claim that it has to do
with the number of in-flight memory accesses, but actually IA-64 shone
on SPEC FP (where in-flight memory accesses are more important than
for SPECint), so it seems that there are ways to get the needed
in-flight memory accesses with in-order execution.
IA-64 had 2× the number of pins compared to its x86 brethren.
No wonder it could consume more BW.
What is GHW?
From what I read, the Model 91 was considered a technical (and
marketing) success, but commercially a failure (sold at a loss, and
therefore quickly canceled). But apparently the market benefit was
enough that they then built the 360/195 and 370/195. 15 91s were
built and about 20 195s. The 195 was withdrawn in 1977, and AFAIK
that was the end of IBM's supercomputing ambitions for a while. This
may have had to do with the introduction of the Cray-1 in 1976 or the
IBM 3033 in 1977. IBM eventually announced the optional vector
facility for the 3090 in 1985. OoO processing vanished from S/360
successors with the 195 and only reappeared quite a while after it had appeared in Intel and RISC CPUs.
At the end, the influence of 6600 on computers we use today is close to
zero. On the other hand, influence of S/360 Model 85 is massive and
influence of S/360 Model 91 is significant, although far less than the
credit it is often given in popular articles.
Back at their time 6600 was huge success and both Model 85 and Model 91
were probably considered failures.
At the end, the influence of 6600 on computers we use today is close to
zero.
On 2024-07-22 3:05, Lawrence D'Oliveiro wrote:
On Sun, 21 Jul 2024 22:21:41 +0000, MitchAlsup1 wrote:
IBM CEO said something to the effect:: How can a team of 24 people,
including the janitor, beat IBM ??
From Watsons memo:
Last week Control Data had a press conference during which they
officially announced their 6600 system. I understand that in the
laboratory developing this system there are only 34 people,
including the janitor. Of these, 14 are engineers and 4 are
programmers, and only one person has a Ph.D., a relatively junior
programmer. Contrasting this modest effort with our own vast
development activities, I fail to understand why we have lost our
industry leadership position by letting someone else offer the
worlds most powerful computer.
Per Wikipedia, Cray's reply was sardonic: "It seems like Mr. Watson has >answered his own question."
On Mon, 22 Jul 2024 13:41:40 +0000 mitchalsup@aol.com (MitchAlsup1)
wrote:
CDC 6600 had a RISC instruction set !!It has RISC-like features, most importantly load-store architecture.
Simple instruction formats and only two instruction width options also
sound RISCy. But hard coupling between A registers and X registers does
not look like RISC to me.
Of the general-purpose systems having the largest fraction of total
installed value ...
On Mon, 22 Jul 2024 10:43:44 +0300, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
On 2024-07-22 3:05, Lawrence D'Oliveiro wrote:
On Sun, 21 Jul 2024 22:21:41 +0000, MitchAlsup1 wrote:
IBM CEO said something to the effect:: How can a team of 24 people,
including the janitor, beat IBM ??
From Watsons memo:
Last week Control Data had a press conference during which they
officially announced their 6600 system. I understand that in the
laboratory developing this system there are only 34 people,
including the janitor. Of these, 14 are engineers and 4 are
programmers, and only one person has a Ph.D., a relatively junior
programmer. Contrasting this modest effort with our own vast
development activities, I fail to understand why we have lost our
industry leadership position by letting someone else offer the
worlds most powerful computer.
Per Wikipedia, Cray's reply was sardonic: "It seems like Mr. Watson has >>answered his own question."
While IBM did not appear to understand the wisdom in Cray's remark at
the time - that a large organization can have internal politics and communications overhead and other things that hamper innovation - it
did _eventually_ learn its lesson.
So when it came time for IBM to make its mark in the new, emerging
field of microcomputers, it had a small team, working in isolation
from the rest of IBM, go and design the IBM Personal Computer in all
its 4.77 MHz 8088 glory.
John Savard
Yes, all modern computers have virtual memory (which started with Atlas
(and later S/360 Model 67), they have caches, which started with Titan
(and later S/360 Model 85), they have reservation stations (which
started with S/360 Model 91).
The largest a team should be is 11 + leader--Jesus tried for 12 and
failed.
IBM patents and disclosures on multithreading include:
...
The whole thing was shutdown when it was decided to
add virtual memory to all 370s ... which was decided not practical for
195.
While IBM did not appear to understand the wisdom in Cray's remark at
the time - that a large organization can have internal politics and communications overhead and other things that hamper innovation - it did _eventually_ learn its lesson.
So when it came time for IBM to make its mark in the new, emerging field
of microcomputers, it had a small team, working in isolation from the
rest of IBM, go and design the IBM Personal Computer in all its 4.77 MHz
8088 glory.
Basically, the hardware would modify the branch opcode in memory after
every branch to track the last two taken/not-taken states.
The largest a team should be is 11 + leader--Jesus tried for 12 and
failed.
On Mon, 22 Jul 2024 17:51:21 +0300, Michael S wrote:
On Mon, 22 Jul 2024 13:41:40 +0000 mitchalsup@aol.com (MitchAlsup1)
wrote:
CDC 6600 had a RISC instruction set !!It has RISC-like features, most importantly load-store architecture.
Simple instruction formats and only two instruction width options
also sound RISCy. But hard coupling between A registers and X
registers does not look like RISC to me.
RISC-V is adopting a very similar idea, in preference to the
widespread current SIMD fashion.
On Mon, 22 Jul 2024 13:08:27 +0300, Michael S wrote:
At the end, the influence of 6600 on computers we use today is
close to zero.
He pioneered pipelining
and multiple function units.
He went on to
pioneer vector processing (long vectors, not the short-vector SIMD
stuff that infests CPU designs today).
He was always very
conservative in the fabrication technologies he adopted, but he was
brilliant at pushing them to their limits.
On Mon, 22 Jul 2024 10:43:44 +0300, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
On 2024-07-22 3:05, Lawrence D'Oliveiro wrote:
On Sun, 21 Jul 2024 22:21:41 +0000, MitchAlsup1 wrote:
IBM CEO said something to the effect:: How can a team of 24
people, including the janitor, beat IBM ??
From Watson’s memo:
Last week Control Data had a press conference during which
they officially announced their 6600 system. I understand that in
the laboratory developing this system there are only 34 people,
including the janitor. Of these, 14 are engineers and 4 are
programmers, and only one person has a Ph.D., a relatively
junior programmer. Contrasting this modest effort with our own vast
development activities, I fail to understand why we have lost
our industry leadership position by letting someone else offer the
world’s most powerful computer.
Per Wikipedia, Cray's reply was sardonic: "It seems like Mr. Watson
has answered his own question."
While IBM did not appear to understand the wisdom in Cray's remark at
the time - that a large organization can have internal politics and communications overhead and other things that hamper innovation - it
did _eventually_ learn its lesson.
So when it came time for IBM to make its mark in the new, emerging
field of microcomputers, it had a small team, working in isolation
from the rest of IBM, go and design the IBM Personal Computer in all
its 4.77 MHz 8088 glory.
John Savard
On Mon, 22 Jul 2024 15:09:22 GMT, Scott Lurndal wrote:
Basically, the hardware would modify the branch opcode in memory after
every branch to track the last two taken/not-taken states.
Did the Burroughs share code between processes/threads?
I don't like how IBM screwed interrupts architecture of IBM PC,
completely ignoring Intel's recommendation to assign hardware
interrupts to INT #32 and higher.
The unnecessary mess they created had negative effect for a long time,
15 years at least.
Also I am not sure that at time (1981) 8250 was the optimal choice for
UART chip.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Mon, 22 Jul 2024 15:09:22 GMT, Scott Lurndal wrote:
Basically, the hardware would modify the branch opcode in memory after
every branch to track the last two taken/not-taken states.
Did the Burroughs share code between processes/threads?
Large systems (B6500 descendents) was multithreaded from the start.
On Tue, 23 Jul 2024 13:20:21 GMT, Scott Lurndal wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Mon, 22 Jul 2024 15:09:22 GMT, Scott Lurndal wrote:
Basically, the hardware would modify the branch opcode in memory after >>>> every branch to track the last two taken/not-taken states.
Did the Burroughs share code between processes/threads?
Large systems (B6500 descendents) was multithreaded from the start.
Not quite what I asked. I was wondering how those code patches would
impact on shared code.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
I was wondering how those code patches would
impact on shared code.
Global branch prediction, of course.
On Wed, 24 Jul 2024 13:22:46 GMT, Scott Lurndal wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
I was wondering how those code patches wouldGlobal branch prediction, of course.
impact on shared code.
But the characteristics of a program run in one thread/process might not match those in another. If both runs are modifying the same code, the
reasons will be ... sub-optimal.
On Wed, 24 Jul 2024 13:22:46 GMT, Scott Lurndal wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
I was wondering how those code patches would
impact on shared code.
Global branch prediction, of course.
But the characteristics of a program run in one thread/process might not >match those in another.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 24 Jul 2024 13:22:46 GMT, Scott Lurndal wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
I was wondering how those code patches would
impact on shared code.
Global branch prediction, of course.
But the characteristics of a program run in one thread/process might not >>match those in another.
They might not, or they might.
When the hardware branch predictor
researchers looked into it, they found that there is more synergy than >interference.
Consequently, they did not take measures to avoid
sharing. And for the approach of patching the hints in the code, the
results of sharing will be beneficial on average, too, because the
only difference from the 2-bit/branch predictor is that the latter is
in microarchitectural state instead of in the code.
Now somebody will point out that sharing makes it possible for an
attacker to train branch predictors in one process to attack a
different process through Spectre and friends. While preventing
sharing would close that, it does not close training the predictors in
the same thread.
Closing Spectre through invisible speculation (several papers exist
about that) makes it irrelevant (for Spectre) whether the predictors
are shared or not. Of course, for invisible speculation the permanent
branch predictors must not be updated speculatively, but that's
probably better anyway.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 24 Jul 2024 13:22:46 GMT, Scott Lurndal wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
I was wondering how those code patches would
impact on shared code.
Global branch prediction, of course.
But the characteristics of a program run in one thread/process might not >>match those in another.
They might not, or they might. When the hardware branch predictor researchers looked into it, they found that there is more synergy than interference. Consequently, they did not take measures to avoid
sharing. And for the approach of patching the hints in the code, the
results of sharing will be beneficial on average, too, because the
only difference from the 2-bit/branch predictor is that the latter is
in microarchitectural state instead of in the code.
Now somebody will point out that sharing makes it possible for an
attacker to train branch predictors in one process to attack a
different process through Spectre and friends. While preventing
sharing would close that, it does not close training the predictors in
the same thread.
Closing Spectre through invisible speculation (several papers exist
about that) makes it irrelevant (for Spectre) whether the predictors
are shared or not. Of course, for invisible speculation the permanent
branch predictors must not be updated speculatively, but that's
probably better anyway.
- anton
On Thu, 25 Jul 2024 10:59:16 +0000, Anton Ertl wrote:
Now somebody will point out that sharing makes it possible for an
attacker to train branch predictors in one process to attack a
different process through Spectre and friends. While preventing
sharing would close that, it does not close training the predictors in
the same thread.
Not allowing a dependent AGEN to happen when the first AGEN takes
a fault ALSO prevents SPectré like attacks
Then not modifying
any cache prior to instruction retirement cements the door closed.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 04:23:55 |
| Calls: | 10,387 |
| Calls today: | 2 |
| Files: | 14,061 |
| Messages: | 6,416,782 |