CDC 6600 - Why so awesome?

[Swift Griggs]

On Wed, 22 Jun 2016, Chuck Guzis wrote:
> I think Paul's covered that pretty well.  I'll add that the more complex
> the display, the more flicker was present.

The descriptions are fascinating. I hope I can see one operating some day. 
Do you know of any still operational ?

> >> Much of the architectural concept was shared with IBM 7030 STRETCH 
> >> (another system worth researching).
> > Hmm, I've never heard of it. I'll check it out. Thanks. 
> Do check it out--there was some bleeding-edge technology that went into
> that system that was later used by Cray in his 6600. 

So far my only comment on the Stretch is "I also hate project managers." 

> One of those project that could be said to be a technical success, but a 
> financial fiasco.

I'm always happy to see corporations lose (scads of) money for a good 
cause. Hmm, now that I think about it, it doesn't even need to be a good 
cause. :-)

> Well, SCOPE had INTERCOM, an interactive facility, as well as 
> EXPORT/IMPORT which was an RJE facility.  But the system was targeted 
> primarily at batch jobs.

Hmm, after reading the responses, I'm guessing most folks just showed up 
with an armload of punch cards and didn't bother with keying things on the 
console at the altar of the system.

> Its illegitimate relative, KRONOS, made extensive use of ECS for support 
> of the PLATO system.  Note that the 6000 series had no hardware memory 
> management to speak of. 

Well, it probably didn't need to do much multi-process multi-tasking, so 
that probably still worked out fine vis-a-vis the competition.

> An active job had a relocation address (RA) and field length (FL), but 
> memory space belonging to a job was contiguous and present in physical 
> memory (no paging or segmentation).  So jobs were moved or "rolled out" 
> to mass storage as needs for resources arose.

Could you roll them back in by just re-populating memory with the dump and 
hooking back to whatever the equivalent of PC and EIP were on that system 
and re-launching the job?

>  So that was for standard offerings--"special systems" (i.e. spooks) had 
> their own adaptations, probably still classified today.

I'm not fond of them. They waste a ton of money (classified budget!?) on 
projects that never see the light of day. I contrast their efforts with 
folks like NASA where a lot of (amazing and super important) tech found 
it's way to the public domain. I would cheer to see them de-funded, 
renamed, and irrelevant. 

> However, there was more than one SCOPE--and when reading the bitsavers 
> stuff, you have to be careful.

Ah, okay, good to know.

> So SCOPE 2 was developed for the 7600.  In it, PPs are relegated to I/O
> and (one very special unit) for maintenance.

Awww, darn. I thought that was pretty cool about the 6600, actually. Time 
marches on, I guess.

>  The operating system proper resides in a set of "nested" program units.  
> That is, there would, for example be a Buffer Manager with an RA and FL 
> that encompassed the Record Manager program, which, in turn would 
> encompass the Job Supervisor...and eventually the user program itself.  

Thanks for that description, that helps a lot, actually. I'm an "applied" 
guy and I'm not very imaginative when it comes to theoreticals. So, 
knowing the nuts and bolts operational stuff helps me to understand how 
the abstract parts fit together.

> A system of "rings of protection" if you will, long before that was in 
> vogue. Although bulk core (LCM = large core memory; the 7600 term for 
> 6000 ECS) was used as program storage,

> [...] the whole affair turned out to be more cumbersome than originally 
> envisioned.  The SCOPE 2 folks were always a little defensive about this 
> result of necessity.

Hehe, isn't that always the way it goes. Version 2 is always much harder 
to get right.

> CDC was sharply split in culture as well as geography--the Minnesota 
> clan was cut from different cloth than the Palo Alto-then-Sunnyvale 
> clan, so discussions from the West coast tend to be more SCOPE-oriented, 
> while the pickled watermelon rind clan talks fondly about KRONOS.

Interesting! I really like little tidbits like this when I'm piecing 
together a "system narrative" again, it puts some things in perspective. 

> Working with full words and shifting and masking can be remarkably 
> efficient. 

Sure it can. I've done that on the M68k before, too. It's a mechanism I've 
used for to create more complex mechanisms. Rotate with carry was 
something I often found useful, too, since I could use the carry bit for a 
conditional jump.

> I recall the "what do we do about more than 64 characters" discussion 
> was raging.  One interesting alternative proposed was to fit 7.5 8-bit 
> characters to the word, with the odd 4-bit leftover being called a 
> "snaque" (snaque-byte; get it?).

Hehe, clever. 

> Instead what was done was to reserve some of the lesser used characters 
> of the 64-character set as "escape" codes for what amounts to 12-bit 
> characters.  So, in theory, you get the advantage of uppercase 
> compatability, while providing for an extended character set.  Very 
> messy.

I guess that's working with what you have, though.

> As an aside, take a look at the UNIVAC 1107/1108 instruction set from 
> roughly the same period.  It has an instruction to define the byte size 
> (36 bit words).

Hmm, interesting. I can't really even wrap my head around the 
implications. If you can't change the register sizes, why would you want 
to do that ? Was it just to shorten certain operations by increasing or 
decreasing their width ?

> Another cultural difference.  CDC had coding standards.

Well, they picked ones that are soothing to mine eyes. 

> http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/nos/NOS_COMPASS_Coding_Standard_Jun83.pdf 
> You develop a disciplined style and you never forget it.

That's a pretty micromanaging standard, though (I skimmed it). I can just 
see some style-nazi jerkhole in the back with the guide nitpicking 
everyone's comma placement. "How DARE you put a space before the comma on 
the destination operand!" *apoplectic choke*.  Still, I've had gigs where 
there was no style guide and it can create stress and friction between 
coders. So, I guess it's better to have one than to just have the wild 
west. Otherwise, you'll give people a pass who want to show you how clever 
than can be in various extremely annoying ways. In C, it's usually someone 
who thinks it's cool to use one-letter variables for everything, and make 
all his lines 180 columns long. I've never had to peer review someone's 
ASM. It'd be pretty painful, I think.

-Swift