Reproduction micros

[Pete Turnbull]

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[1], 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.

[1] 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 [2].

[2] 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.

-- 
Pete