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
