> On Feb 17, 2025, at 12:30 PM, Chuck Guzis <[email protected]> wrote:
>
> On 2/17/25 06:17, Paul Koning wrote:
>
>> 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.
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.
> 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
