In article ,
Morris Dovey wrote:
On 4/12/2010 8:07 PM, Robert Bonomi wrote:
In ,
Morris wrote:

Yuppers on the oddness - my impression was that the CDC management team
had never quite been able to decide what they wanted to do when they
grew up. At one point they were even in the windmill business.

And they built computers that couldn't add!

They faked addition by 'complement and subtract'. (true!!)

That said, they were some of my favorite hardware to work on.

Was it the IBM-650 that was nicknamed the "CADET" for Can't Add, Doesn't
Even Try?

Yuppers. It simulated addition via table-look-up. I never programmed on
one of those.

The only CDC machine I ever used was the 6500 at Purdue and it seemed to
do crank right along fair reliably.

The 6000 series were nice machines, but they did have their quirks.

I, *unintentionally*, was responsible for one University machine crashing
nearly _two_dozen_ times in approximately a 1-week period. This accounted
for over 90% of all the crashes the machine experienced in two years.
WRY GRIN

It took a while to establish cause-and-effect, because *nobody* was willing
to believe that that 'innocent little job" -- nothing more than 4 standard
statements in the system control language -- could _possibly_ be the culprit.
Until they ran it as the _only_ job in the system, and watched the machine
crash.

The entire job consisted of:
1) request a tape mount
2) copy a file from disk to the tape
3) rewind the tape
4) copy from the tape back to a new file.

{_first_ time using a mag tape, and was checking my understanding of 'how
things worked.}

The job _never_ got to step #4

The log file showed a bunch of strange messages, that -nobody- (I took it
to the help desk, asking "what's thin mean?") understood. The help desk
would puzzle over the job output, look at the 4 punch-cards, look back
at the log, say "*OH*!! that was when the system crashed, why don't you
try running it again." so I did, when I next had a chance. *sigh*

Experimentation showed that it was the "rewind the tape" command, itself,
that was crashing the system.

The high-level architecture was positively elegant in it's simplicity and
regularity.

the closer to the hardware they got, the *stranger* things got.

Speaking of Burroughs... )

I think the 6600 had Burroughs beat -- it could *lie* to you in the core-
dump of a program that aborted due to a hardware exception (e.g. address
out-of-range, using an 'infinite' operand {result of 'n' divided by zero}
or using an 'indefinite' operand {result of dividing zero -by- zero}).

i.e., the program attempted to perform that illegal operation, generated
a hardware exception which triggered a core dump, and there was *NO*
evidence in _any_ register of the 'illegal' data that triggered the
exception.

The systems programmers, just for fun, handcrafted a small assembler-code
program that triggered _all_three_ of the possible exceptions, _and_
entirely covered it's tracks in the core-dump.