On 10/31/24 10:39 AM, Paul Koning via cctalk wrote:
> On Oct 31, 2024, at 11:41 AM, Chuck Guzis via cctalk<cctalk(a)classiccmp.org>
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}(a){jlw,jxh}.com first.last(a){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