17 Feb
2025
17 Feb
'25
11:38 a.m.
On Feb 17, 2025, at 12:30 PM, Chuck Guzis
<cclist(a)sydex.com> wrote:
On 2/17/25 06:17, Paul Koning wrote:
Yes, though it's possible to enable such things with condition code machines if the
setting of the condition code is selective. The Electrologica machines have this: there
is an instruction modifier bit that tells the machine to update the condition flag based
on result zero, result positive, or a third option that I never remember -- or to leave it
untouched. Subroutine calls save the flag and the return can restore it if you want, or
not if you don't. Finally, almost all instructions can be conditional on the flag if
you want, either "execute if flag set" or "execute if flag clear" or
unconditional. The EL-X1 Wikipedia article shows an example.
Also multiple functional units, seriously
interleaved memory, and a bucket full of other tricks. The way loads and stores are
requested by the programmer naturally makes them background operations, and the
"stunt box" handles that background process.
Even on the lower 6000 (6400/6500), the architecture made a large
difference. Three-address architecture (c=a+b vs. a=a+b) and the lack
of condition codes enabled more code "movement". That is, you could,
for example, compute a value at the top of a loop and have the branch on
condition at the bottom. Hand optimization for the 6600 was a big thing for
standard product
development (cf. Jack Neuhaus' code optimization classes) and it gave
one a chance to be "clever". Rick James and Richard Frank came up with
a lot of "interesting" code, such as doing 10-digit display code
addition/subtraction as a parallel operation.
I don't know that one, but there is the famous OTOD -- convert a 60-bit value to a 20
digit octal string. I did a variation on that (not quite as slick) to convert a 60-bit
value to a 15 digit hex string.
I was pretty good at hand optimization, but for
complex loops, I'd write
the code in FORTRAN so that FTN and look at the generated code and work
from there.
Interesting. I worked on a 6500 so a lot of optimizations were not relevant, but I spent
a while studying code in NOS to learn how to do it. One thing that did matter was
shuffling instructions around to avoid NOP padding. I once had a piece of code that was
subject to hard real time constraints -- which I did not know -- so when I broke it I had
to revise it to get rid of all the NOPs. Then it was fast enough again.
On the subject of exchange jumps, I should point out
that for a very
long time, use of the feature was restricted to the PPUs--i.e. the
CEJ/MEJ switch on the deadstart panel was "off"--OS user requests were
exclusively through the RA+1 mechanism.
Really? I never heard of anyone who ran with CEJ disabled -- why would you want to do
that?
One of most ingenious coding tricks to me was the
problem of saving and
restoring all registers without resorting to an exchange jump. We used
that one as a test for applicants.
Oh yes...
All in all, I'd consider the CDC 6600 to be the
crowning glory of
Seymour Cray's career.
Indeed, though I sure would like to know how to make the timing work. If you do
what's documented in the schematics (in a VHDL model) it doesn't work.
paul