🚀 go-pugleaf

>>The point I want to make is that if RISC (or anything else) keeps the 
>>instruction cache 100% busy, THAT IS GOOD, NOT BAD. 
>
>Actually, it is bad.
>Keeping the i-cache 100% busy means it is the bottle neck, so the original
>argument applies.

If 100% busy means that the instruction cache is always missing, yes, it
is the bottleneck.  If 100% busy means that the instruction cache is
delivering an instruction to the processor every cycle, no it is not the
bottleneck.  Assuming the processor can execute 1 instruction per cycle and
the instruction cache is delivering 1 instruction per cycle (a safe
assumption for a RISC machine with a Harvard implementation), the
instruction cache is NOT the bottleneck.  The instruction cache and
processor are working at their maximum rates, a fact which indicates a
good design.

I thought it was clear that by 100% busy, I meant delivering an instruction
to the processor on every cycle (or very nearly so, which is the case for
most RISC machines).

Similarly, if the processor's instructions specify two source registers and
one destination register and the register file can source two operands and
sink one operand, the register file is not the bottleneck, even for a long
sequence of arithmetic/logical/shift ops in which the register file is kept
100% busy.