Brendan (btrotter.delete@this.gmail.com) on February 21, 2019 9:07 am wrote:
>
> My definition of RISC is that there's a reduced number of instructions (not a buttload
> of instructions with a different instruction for each occasion, like 80x86, or ARMv8).
>
> I've seen others define it as "no micro-code". I've seen more people define it as "load/store architecture
> that may be extremely complex". I've seen people define it as "designers were too lazy to bother
> doing anything complex/good". I've seen people suggest it's "fixed instruction size".
>
> To be honest, I'm thinking the only true definition of RISC might be "meaningless marketing hype for fools".
>
> - Brendan
>


Today almost everyone who posts on such forums uses the word RISC with a slightly different meaning than everybody else. This is mostly OK, because everyone should organize information in his head using whatever labels work for him, but it also has the undesirable consequence that it leads to many unproductive discussions when people argue only because they did not define the words they are using.


In the beginning, RISC had a quite precise meaning, but few use the word RISC with that sense.

The acronym is not the most appropriate, because the goal of the set of RISC rules was not to have a reduced instruction set.

The set of RISC rules was a recipe to design a CPU which had 2 performance goals:
1. To reach a rate of execution of 1 instruction per clock cycle
2. To have a clock frequency equal to the maximum value achievable in the available technology for the execution in 1 clock cycle of simple operations, i.e. register-to-register word-sized integer additions

To the 2 performance goals there was an additional constraint, to achieve those goals in a die area small enough for the LSI circuits of that time.


All the RISC rules were derived from these goals and they were indeed a good recipe, as proven by many successful designs that followed them.


The small set of instructions resulted from the following rules derived from the goals:


1. No instruction should be included in the ISA if its implementation would require an increase in the complexity of the processor that would determine a decrease of the clock frequency.

2. If the first rule is verified and the instruction can be executed in 1 clock cycle, it may be included in the ISA.

3. If the instruction needs multiple clock cycles for execution, it should not be included in the ISA, because the same result can be obtained with a sequence of simple instructions.


However, the third rule was proven to be wrong very soon, so most RISC designs have replaced it with a modified rule.

The rule about multicycle instruction was justified when the RISC processors were compared with low performance microprogrammed processors, because there the complex instructions were indeed implemented as a sequence of microinstructions. Because the RISC simple instructions were equivalent with the microinstructions of the earlier computers, implementing the complex instructions as a sequence of simple instructions could easily achieve a competitive performance.


Nevertheless, when attempting to introduce real products based on RISC designs, it became clear immediately that for competitive performance with the other mid-eighties computers it was necessary to also implement in hardware more complex operations, the most obvious example being the floating-point operations.


So the third rule had to be modified like this:

3. If the instruction needs multiple clock cycles for execution, then it must be executed in a separate functional unit, so that after a multicycle instruction is issues, simple instructions can continue to be issued and executed in every clock cycle.


With the modified RISC ISA rules, the 2 RISC performance goals can still be reached.

Nevertheless, in this case there is an obvious problem, the 1 IPC goal can be reached only for certain instruction sequences, when you are lucky to have enough independent simple instructions to be executed in parallel with the multicycle instructions.

For many other instruction sequences, there will be stalls, e.g. when an instruction needs a multicycle functional unit that is not free because a previous instruction is in progress, or when an instruction depends on the result of a unfinished multicycle instruction or when the output register of an instruction is read or written by a previous still unfinished instruction.

During the eighties, many research papers were published, discussing various methods of improving the performance of RISC processors, then all those methods were used in real products during the nineties.

Almost all processors that are now called "RISC", with the exception of some low-end microcontrollers, are not RISC in the original sense, but can be seen as derived from a basic RISC processor by adding many post-RISC performance-enhancement features.

Examples of now well-known methods that were proposed during the eighties for increasing the performance of the RISC processors:
- elimination of the stalls due to a busy multicycle unit by making it "superpipelined", i.e. able to initiate in every cycle the execution of independent multicycle instructions
- using either more registers or register renaming to eliminate the stalls due to a shared output register
- out-of-order initiation of instructions, to eliminate all stalls, including those due to dependencies
- going beyond 1 IPC with either VLIW (1983) or superscalar (1987) instruction decoders
- eliminating the stalls due to shared functional units by replicating them
and so on.


The only performance-enhancement method for which I am not aware of an origin before 1990 is SMT. The earliest reference known by me was in 1992 (cited in the 1997 paper that introduced the name "SMT").


While most post-RISC features are at the microarchitecture level, so that they are not visible at the ISA level, a few are architectural, e.g. vector instructions and SMT.


Already in 1988, the research paper from DEC that introduced the word "superpipelined" discussed various methods to enhance the performance of a basic RISC processor and identified 3 orthogonal methods: vector, superscalar and superpipelined.

At that time, because the implementation costs were still large, there was a debate about which is the best method, even if it was already clear that one can use all methods simultaneously. In modern processors, all methods are used, e.g. simple operations are superscalar, complex operations are superpipelined and important complex operations, e.g. FMA are vector and superscalar and superpipelined.




So the conclusion of this historical comments about the original meaning of "RISC", is that dmcq was partially right and partially wrong.


He was right that vector instructions cannot be considered RISC instructions.

Nevertheless, vector instructions can be added to a base RISC instruction set without contradicting in any way the RISC rules, as already noticed in several papers during the eighties.


Adding vector instructions to a RISC processor does not make it less RISCy.
It just becomes both a RISC processor and a vector processor.