pete at dunnington.plus.com
Wed Jul 20 10:17:07 CDT 2016
On 20/07/2016 14:56, Noel Chiappa wrote:
> 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.
At least for some RISC, that's more than a side effect. While at Acorn
in about 1987, I attended talks run by Sophie Wilson and Steve Furber
where they described some of the design criteria for ARM. They were
very clear that the design goal was for every instruction to be executed
in a single cycle, not just discarding longer instructions. Thus the
process wasn't about removing instructions but rather about deciding
what (instructions and hardware) to put in as necessary and useful, so
that more complex operations could be built up from short sequences of
very fast instructions. Kind of like the Unix philosophy of pipelining
small utilities, in a way.
They also studied what had gone before: IBM 801, the Berkeley RISC
project, Clipper, and others. Steve describes some of this in his book
"VLSI RISC Architecture and Organisation", which is a good read if you
can find a copy.
 actually it's three clock cycles - fetch,decode,execute - but
there's a three-stage pipeline so although the duration of any given
instruction is 3 clocks, overall you get one instruction per clock .
 except I'm simplifying; for example there's only one memory port so
load and store instructions take an extra cycle, since they need one
memory access for the instruction fetch and one for the data - or more
if it's a block data transfer, obviously. And BTW it does have a mode
to take advantage of reduced access times for sequential access in
memories that support it. That's why the data sheets quote instruction
times in terms of S (sequential) and N (non-sequential) cycles.
More information about the cctalk