Talk:CDC 6600

message: Programmers tended to treat PPU programming as if each PPU was a completely independent computer, and as if the other PPUs did not exist. That was a direct result of the barrel architecture. 
As for interaction with the CPU, this did not exist; central memory was read or written from the PPU as if it were some kind of simple device without an explicit channel number. The execution of the CPU was not affected by PPU programs, with the solitary exception of the PPU monitor.
Altho the article correctly observes that I/O was the province of the PPUs, they were remarkably ill-suited to the task. For example, they possessed no interrupt architecture. Therefore, PPU programmers had to code delay loops which repeatedly checked device statuses. The resultant code was very painful to write due to the numerous loops and exit conditions. To write I/O interfaces casually ignoring device status was to invite PPU hangs which would gradually degrade the entire operating system.
* I find this description to be quite inaccurate.  Interaction between PP and CP of course did exist -- via shared memory data structures.  Indeed, the circular buffer approach used is very efficient and handles concurrency correctly without any need for interlocks.  As for "remarkably ill-suited to the task" -- not at all.  WIth enough PPUs that each I/O device had its own, lack of interrupts is not a real issue.  The only thing you might argue is that this approach was unfamiliar to programmers.  Perhaps less so early on, because interrupts were not universally used in the 1960s (consider the 1620 -- synchronous I/O on a single processor machine).  The proof is in the pudding.  PLATO was a 1000 terminal, 600 user timesharing system, highly interactive, very high I/O rates, running on just two Cyber 73 class machines (combined power about the same as a single 6600).  I submit that such a project would have failed miserably if it were even close to true that PPs are ill-suited to doing I/O.  In fact, they did very well, provided you have good programmers working on the job. Finally, re "each PPU an independent computer" -- naturally, since that is in fact what they are, except for the shared access to the I/O channels.  The OS would manage that access.  Also, there were a few cases where multiple PP programs would cooperate on I/O -- high speed disk I/O for example (at PLATO) or long-block tape I/O (standard OS feature). Paul Koning (talk) 16:01, 9 November 2009 (UTC)
thread_title:  How systems programming was affected by 6600 Architecture 

message: I removed the sentence beginning with "For instance, a program might use..." because the suggested interaction of CPU and PPU programming never occurred in actual practice.
The PPU were reserved for the exclusive use by the operating system and primarily for I/O operations, inasmuch as the PPU could access the data channels and the CPU could not.  Because of this, PPU were not employed to assist in CPU computations or logic, even though the "virtual" concurrency of execution in CPU and PPU might offer the possibility.
PPU programming language was easily acquired because the same assembler could interpret both CPU and PPU mnemonics; however, PPU programs could access the entire machine's memory and the data channels. Hence amateurs were forbidden to load code into PPU by a number of preventative measures, not the least of which was the absence of an operating system command or process for seducing the system to do that from a user's job stream.
The easest way to load a custom PPU program was to go to the bootstrap panel and tell it to load from tape to PP0 on reset.  Push the reset button and your code loaded.  Other than that it was almost imposible to get a PP program loaded.  The monitor was in charge of telling each PPU what to load next.
At Michigan State University (MSU) SCOPE was "enhanced" into "Scope/Hustler" as a pun on the way that user jobs were "hustled" in and out of control points (jobs ready to run).  In order to improve performance parts of the PPU Monitor function were moved to the CPU.  The monitor then forced a Context jump on the tick at which point the CPU would run the control points to find the highest priority job that was ready for the CPU and the context jump into that user job.
The other major improvement (Not sure if this was in SCOPE as I was writing for SCOPE/HUSTLER) was that the RA+1 calls (system calls) were improved by having the user programs execute an intentional illigal operation.  When this happened the user job did a context switch to the OS which processed the RA+1 call and then dropped into the scheduling process.
This meant that the CPU was only interupted when the user job wanted a function from the OS OR when the PPU Monitor wanted to make sure that the CPU got some cycles.  — Preceding unsigned comment added by 24.62.5.242 (talk) 19:39, 1 August 2012 (UTC)
thread_title:  How PPU were actually used 

message: I used a CDC 6400 and a Cyber 70/74.  From what I knew at the time, the Cyber 70 was basically the same as the 6600.  If I'm correct, the 6600 was one of the last second generation computers and the Cyber 70 was 3rd generation.  Are these things correct?  -
Also, in the second paragraph under Central Processor, "CU" is used one time.  Is that supposed to be CP?  I assume it is, since someone changed it in other places, so I'm going to take the liberty to change the remaining CU -> CP.  Someone correct this if I'm wrong.
-Bubba73 02:56, 6 Jun 2005 (UTC)
thread_title:  6600 and Cyber 

message: [CONTROL DATA 6400/6500/6600 COMPUTER SYSTEMS Reference Manual]:
47  CXi  Xk  Count the number of "1's" in Xk to Xi  (15 Bits)  
 
"This instruction counts the number of "1 's" in operand register Xk and stores the count in the lower order 6 bits of operand register Xi. Bits 6 through 59 are cleared to zero." <P> Grishman (1974) gave a silly reason for this opcode, as if storage were so tight that packing individual BITS might be good practice.  I have never been able to come up with any commercial application that would find this useful.  Where it would be useful is in ciphers and cryptology at the NSA level. <P> As the article notes, "Most of these [50 CDC-6600 ever built] went to various nuclear bomb-related labs."  It seems to me that this opcode wouldn't have found its way into the germanium, I mean silicon, without some Federal involvement in original design.  Comments?  Tribune 16:30, 12 July 2005 (UTC)
thread_title:  'Population Count' ("Count Ones") Instruction 

message: In the early 1970's I was told that pop count was added to the instruction set at the specific request of one particular US government customer who had been given a demonstration of the earliest 6600.  Once the custom circuit modules were designed, it made no sense to omit them from successor machines.  
The circuits for pop count were trivial.... literally a bunch of adders in a tree.   But there was a indeed a desire on the part of NSA to have the instruction for doing set intersection and counting the size of the result.  The instruction has other uses as well, including looking for a physical disk position that has at least n blocks available.  The instruction was NOT, however, particularly slow, despite being implemented in the divide unit: it was 8 minor cycles, slightly more than a conditional branch (nominally 6, if in stack) and less than a multiply (10).  More philosophically, there's also the observation that it's a function which is easy and cheap to do in hardware, and very slow to do in software.   Since it's useful, put it in. Capek 01:35, 18 August 2006 (UTC)
thread_title:  Comment on Pop Count 

message: Someone with the right enthusiam should include info from these few news articles from 1960s, found with the new Google News Archive Search. I'd just add these to the external links but I don't think they'd get the attention they deserve. The Google News Archive is an amazing insight into the past. :) The first article, from 1961, describes a "huge, advanced-design 6600 computer" to be under development and one, from 1968, how "Four years ago, Minneapolis-based Control Data Corp. brought out its model 6600 computer, the largest machine of its type in the world." I really hope articles about old events, items and people will start getting external links to actual news stories now that we have this new Google service! (Oh, and I'm not paid for endorsing Google like this, I personally just think it's a Good Thing(tm) ;)  --ZeroOne 23:59, 14 September 2006 (UTC)
thread_title:  Google News Archive Search on 6600 

message: In the section on the CP, at the point where it says the stack is flushed by an unconditional branch, it then says unconditional branches are faster than conditional branches.  As I recall, this was the reverse.  Many times used =X0 X0 for "unconditional" branches just to avoid the stack flush.  Should this not read "it was sometimes faster (and would never be slower) to use a conditional jump," rather than "it was sometimes faster (and would never be slower) than a conditional jump"?
Poochner 18:21, 22 March 2007 (UTC)
thread_title:  Branch timings 

message: Since the CDC 6600 was the first computer with a scoreboard for dynamic rescheduling, this should definitely be included in the article. It's mentioned in the CDC 6000 series article, but not here. -- PyroPi (talk) 02:54, 11 May 2010 (UTC)
thread_title:  Scoreboarding 

message: The B-registers are named in the article "scratchpad" registers. As I can remember, at the CDC 6400 they were named "index" registers. Is there a different naming on the CDC 6600? Thanks for the clarification. CeeGee 07:02, 9 July 2013 (UTC)
thread_title:  Register naming 

message: I have seen various versions of the claim that the first 6600 was delivered to CERN a year before the delivery to Lawrence Livermore Lab in California. This is simply not true! The first  6600 was delivered to Livermore Lab. One year before that we were still laying out the artwork for the printed circuit boards and there was no 6600. As I remember it the system we shipped to CERN was serial 4 or 5. 
Oldgoat35 (talk) 17:45, 4 October 2013 (UTC)
thread_title:  Delivery of first 6600 

message: Compared to what I'm  used to, the intro section (before the first numbered section) seems very long and dense. Paul Koning (talk) 00:28, 6 January 2015 (UTC)
replies: text: You are right.  I think the paragraph on the 7600 obviously should not be in the intro, so I moved it.  I think the second paragraph needs to be moved out of the intro too.  Bubba73 You talkin' to me? 00:42, 6 January 2015 (UTC)
replies: text: I moved the second para into a new "Models" subsect of the "Description" sect. I also changed the intro text from referring to "a 6600" to "the first 6600" (because it sounded awkward), but someone needs to verify that the CERN model was indeed the first CDC 6600. — Loadmaster (talk) 17:51, 6 January 2015 (UTC)
thread_title:  Overly long intro? 

message: The discussion of the barrel says that it was partly for cost (sounds right -- not to mention space) and partly because of the CP memory timing which is 10 PP cycles.  That doesn't sound right.  All memory has the same timing (it's after all the same modules), 1000 ns full cycle.  So a CM cycle is one major cycle.  But in any case, the CM to PP interaction is isolated in the "pyramid" so the two timings aren't directly tied together.
The relevant memory timing may instead be that of PP memory.  Given the logic used, execution steps would run at small multiples of 100 ns, but with memory running at 1000 ns that speed would be wasted.  1 microsecond cycle time is fast enough for the intended uses of the PPs, so by having 10 PPs in a barrel, the effective PP execution cycle becomes 1000 ns which perfectly matches the PP memory cycle time.
The key question (by Wikipedia rules) is not really whether this makes sense, but whether we can find a source to cite for it. Paul Koning (talk) 15:01, 7 January 2015 (UTC)
thread_title:  PP and memory timing 

message: Weren't the Peripheral Processors actually called Peripheral Processing Units (PPU)?  Bubba73 You talkin' to me? 04:03, 20 January 2015 (UTC)
replies: text: The documentation for the 6600 calls them CP and PP; the documentation for some successor products calls them CPU and PPU. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:45, 6 October 2019 (UTC)
thread_title:  PP or PPU 

message: CDC 6600 is attributed in The "Bulleting of the American Mathematics Society", volume 72, number 6 (1966), in the paper "Counterexample to Euler's conjecture on sums of like powers" by L. J. Lander and T. R. Parkin with finding 275 + 845 + 1105 + 1335 = 1445, disproving Euler's conjecture of Fermat's Last Theorem. https://projecteuclid.org/euclid.bams/1183528522 --Conspiration 06:46, 25 March 2018 (UTC)
thread_title:  Euler's Conjecture 

message: At the end of the second paragraph it is stated "Approximately 50 were delivered in total.", quoting a later source, whereas in the beginning of the one but last para of the History section it says "More than 100 CDC 6600s were sold over the machine's lifetime.", without source. Any idea how to resolve this discrepancy? --HReuter (talk) 21:24, 5 October 2019 (UTC)
replies: text: Also, do either or both of those numbers include Cyber 70 model 74? Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:43, 6 October 2019 (UTC)
thread_title:  Number of machines delivered 

message: Should the article discuss Monitor Exchange Jump, or would that be TMI? Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:45, 31 May 2020 (UTC)
thread_title:  Monitor Exchange Jump? 

message: Should the register table include an annotation that A1-A5 are used for reading into X1-X5 and A6-A7 are used for writing from X6-X7? 08:20, 20 May 2021 (UTC)
thread_title:  Annotate register table? 

message: I was going to add SIPROS to Timeline of operating systems, but realized that I don't know the date. If anybody knows when and to whom SIPROS shipped, or when CDC dropped it, please update the article. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:42, 6 November 2022 (UTC)
thread_title:  SIPROS 

message: The current text says that the 6600 has a 128 kw address space, which is correct. It then claims that this is because the address registers are signed, which is incorrect. I suppose you could call A registers signed in that they use the standard one's complement arithmetic, but programmers certainly didn't think of them that way and the notion of "signed" doesn't appear anywhere that I know of.
It then goes on to say that later machines allowed more memory (yes, the 170 series) but individual programs were still limited to 128 kw.  Not so; the 170 manual clearly states the FL register in the exchange package is 18 bits, not 17.
In fact, the limitation of the 6600 is related to the physical size of memory of the time: it uses 4k x 12 memory modules, so a 4kw memory bank requires 5 of those, which is two whole rows in a chassis.  A fully loaded 6600 has 32 banks (so 32-way interleaving, yielding more than enough bandwidth to match the 100 ns minor cycle time).   4 banks would go in a chassis, with another 5.5 rows of logic, leaving 3.5 rows unused.  That means a full memory 6600 used 8 memory chassis, i.e., two of the four wings of the + shaped system cabinet.  A half-memory 6600 would have one arm of the + omitted.  A hypothetical 256 kw 6600, or other 6000 series machine with that much memory, would require 16 memory chassis and an entirely different packaging strategy.
In the 170 series the memory technology had changed and density increased so at that point the bigger memory became feasible. Paul Koning (talk) 17:16, 28 September 2023 (UTC)
replies: text: Also, the 18-bit field length applies only to central memory, not to ECS. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:35, 28 September 2023 (UTC)
thread_title:  128 kw address space 

message: The CDC 6600 has a CP ISA and a PP ISA; they are very different. All statements about "the ISA" should be put in context, either explicitly or by putting the two ISAs in separate subsections. I'm not sure which approach is best. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:37, 18 December 2023 (UTC)
replies: text: Probably separate sections. Peter Flass (talk) 06:02, 19 December 2023 (UTC)
thread_title:  CDC 6600 ISA is ambiguous 

message: Should the article mention that the 6600 did not have parity bits, and, if so, where? Also, is there an RS for the statement "Parity is for farmers."?
As a side note, the SUNY/AB 6400 sometimes had problems with dropped bits. It turned out that the best diagnostic for suspected memory failures was the Baseball game played at the console. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:49, 27 February 2024 (UTC)
thread_title:  Parity?