CDC 6600 - Why so awesome?

[Chuck Guzis]

On 06/22/2016 01:58 PM, Swift Griggs wrote:

> 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.

You don't seem to realize how expensive these systems were to operate.
IIRC, the  *internal* COMSOURCE price charged for an hour of block time
was about $500 (that's 1970s dollars, thank you--when $3K would buy you
a nice imported sports car).   There *was* a PP program called o26
(after the keypunch) but used mostly by CEs and systems installation
people.  Using the console of such an expensive machine by ordinary
users would have been viewed as something akin to feeding $20 bills into
a regular keypunch.   Remember, this was in the era of "glass walled
rooms", where only selected people were allowed to touch the machine.

I once made the mistake of trying to mount my own tape at a military
base.  I thought that I was going to be tackled and led away by MPs.
They have people stationed by each bank of tape drives who do nothing
but that all day.  They don't take kindly to someone trying to take
their job.

> 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.

You don't understand.  Big iron did multitasking and multiprogramming,
but the I/O media was cards, tape and printed output.  Going "online"
was expensive and slow in terms of equipment.

> 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?

The rolled-out job didn't lose its files or place in the running job
queue; it just got represented by a placeholder bit of memory (usually
the exchange package) and then read back in when its turn came up.

> 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.

Sometimes the non-classified parts were repurposed.  For example,
TCM/TOOS was used for both USAF Logistics and UBS (Switzerland)
projects.   Called different things, of course and code shared only up
to a point.

Remember that SAGE was classified.  The military and defense industries
were major funders of big iron work.  Who do you think Seymour Cray sold
to as his initial customers for his boxes?

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

There was a lesson to be learned from it--give the I/O to another,
cheaper, machine.   You'll see that philosophy in the later Cray machines.

> 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.

The 6000 had no carry bits; for that matter, it had no condition codes
at all. If you think about it, that makes instruction scheduling much
easier because you don't have to worry about instruction side-effects.
On the X (60 bit registers), you can branch on the sign of a register or
its zero/nonzero contents. B-registers can be queried by a single
compare and branch instruction. It also helps that the 6000 is a
three-address architecture, so you needn't clobber a source register
when testing contents. And the smallest instruction was only 15 bits wide.

> 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 ?

To elaborate a bit, you could divide a word into sixths, halves and
thirds (6, 18 and 12 bit) parcels and operate on each of them.  So not
really a "byte".

> 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.

It was a necessary evil with long product lives, many people, etc.
"Egoless coding".  Try doing something else and you wind up with Linux
code eventually.   Miles of code without a clear comment on what's
happening--or why.

Worse, yet, stupid comments.  I once knew a young programmer who was
quite proud that *every* line of his code had a comment on it--even if
he never explained what he was doing.  e.g.,

	IX6	X3+X4		ADD X3 AND X4 AND PUT SUM IN X6

He carefully explained what each instruction did but not what he was
trying to do.  The old rule of writing "Tell people what you're going to
say, say it--and then tell them what you've said" also applies to
commentary, IMOHO.

--Chuck