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