It kind of pushed their own definition of what RISC is. They also confuse the definition of what a 16-bit computer is and ignore the many commercial successes in 16-bit minicomputers such as the Nova. It is clever to point out that the most useful definition of RISC is that it’s a tradeoff.
The point remains that a simplified ISA that’s easy to decode (and, more recently) implement dynamic reordering, will always have an edge by freeing up resources that can be dedicated to execution of the workload rather than housekeeping (as in resolving all inter-instruction dependencies).
OTOH, going too far in that direction gives you VLIW, which has proven itself to be a pain more often than not.
I kind of agree there is no hard definition because what's "complex" and "reduced" are subjective things. The venerable 6502 was called "RISC before it was cool" and I have to agree its minimalistic ISA made it incredibly capable (and fast, clock for clock) compared to its more ambitious contemporaries such as the Intel 8080/8085, the Motorola 6809, and its arch-nemesis, the Z-80.
The 6502 is nothing like what we would call RISC today (the 6800 is much more modern RISC-like), but the evolution from 6800 to 6502, by largely the same design team at a new company, does somehow follow the RISC "quantitative approach" of getting the most performance from a given number of transistors (the 6800 and 6502 are about the same size), but it does it by adding complexity rather than by simplifying.
> but it does it by adding complexity rather than by simplifying.
That's true - it simplifies a lot of other things alongside the ISA, but it's also apparent that, while it can do a lot of tasks faster than, say, a Z-80, the ISA forces one to take some creative approaches.
Literal ports of Z-80 code to the 6502 usually sucked.
The point remains that a simplified ISA that’s easy to decode (and, more recently) implement dynamic reordering, will always have an edge by freeing up resources that can be dedicated to execution of the workload rather than housekeeping (as in resolving all inter-instruction dependencies).
OTOH, going too far in that direction gives you VLIW, which has proven itself to be a pain more often than not.