Reproduction micros

Noel Chiappa jnc at mercury.lcs.mit.edu
Wed Jul 20 08:56:25 CDT 2016


    > From: Paul Koning

    >> I always felt that RISC meant 'making the basic cycle time as fast as
    >> possible by finding the longest path through the logic - i.e.  the
    >> limiting factor on the cycle time - and removing it (thereby making the
    >> instruction set less rich); then repeat'.

    > "Making the cycle time as fast as possible" certainly applies, in
    > spades, to the 6600.  The deeper you dig into its details, the more
    > impressed you will be by the many different ways in which it does things
    > faster than you would expect to be possible.

My formulation for RISC had two parts, though: not just minizing the cycle
time, but doing so by doing things that (as a side-effect) make the
instruction set less capable. I'm not very familiar with the 6600 - does this
part apply too?

    >> RISC only makes (system-wide) sense in an environment in which memory
    >> bandwidth is plentiful (so that having programs contain more, simpler
    >> instructions make sense)

I should have pointed out that programs of that sort take not just more memory
bandwidth, but more memory to hold them. In this day of massive memories, no
biggie, but back in the core memory days, it was more of an issue.

    >> One of the books about Turing argues that the ACE can be seen as a RISC
    >> machine (it's not just that it's load-store; its overall architectural
    >> philosophy is all about maximizing instruction rates).

I looked, and it's "Alan Turing's Automatic Computing Engine"; in Chapter 8,
"Computer architecture and the ACE computers", by Robert Doran (which is not,
for some reason, listed in the ToC).

    > I think a lot of machine designers, though not all, were seriously
    > interested in making them go fast.

Again, RISC has two legs, not just making the machine fast, but making them
fast by using techniques that, as a side-effect, make them inscrutable, and
difficult to program. The concept was that they would not, in general, be
programmed in assembler - precisely because they were so finicky.

Remember, the 801 was a combined hardware/compiler project, in which
complexity was moved from the hardware to the compiler; and early RISC
machines has things like no interlocks between pipeline stages. So they really
were not intended to be programmed in assembler - the compiler was critical.

The ACE, on the surface, didn't follow this, as it had no compiler. However,
at a higher level, Turing definitely followed the RISC philosophy of making
the machine as fast as possible, by using techniques that made it very hard to
program; instead of moving the complexity to the compiler, he moved it to the
programmer - the latter not being a problem, if you're Alan Turing! :-)

	Noel


More information about the cctech mailing list