On 10/31/24 10:39 AM, Paul Koning via cctalk wrote:
On Oct 31, 2024, at 11:41 AM, Chuck Guzis via cctalk<[email protected]>
wrote:
On 10/31/24 07:35, Donald Whittemore via cctalk wrote:
If I remember right I was told back in the early 70s by our IBM CE that
physical damage could be done to our model 30 or 40 if we ran a program that
did an Assembler instruction, B * For those non-Assembler people that is an
instruction to branch to the location of the instruction. I think it might
have caused a heat problem in the core or CCROS or TROS.
Possible? Or is my 76 year old brain hallucinating?
I recall that sort of thing was an issue in the CDC 7600; it could throw
parity errors because of core heating. I believe that the problem was
in the PPUs, but it's been too many years to remember accurately.
Ahh, yes, the Duty Cycle Integrator. Slows things down when they heat
up. The DECwriter III has a similar feature when you're printing long
lines of dense characters, such as '#'.
I could imagine it in PPs, also in 6400 machines since they don't have an
"instruction stack" so instruction fetches would go to memory. For all of
those you'd end up hammmering a single memory cell at high speed, and each time you do
that you get a read and a write cycle, both of which inject some energy into the cores in
question.
In CDC's OS (NOS) the idle loop contains a couple of instructions which are
fairly slow, apparently with the specific intent to slow down memory references.
A couple divides, or count instructions, though bit counting might not
be as slow as divides on machines that have an instruction stack,
similar to the difference between iterative shifting and a barrel shifter.
--
Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com
Spum bad keming.
Nature abhors a straight antenna, a clean lens, and empty storage.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
"Card sorting, Joel." -me, re Solitaire
