I don't think the point of RISC ever was a minimal instruction set. Heck, there have been (theoretical AFAIK) Turing-complete single-instruction computers. Is anything more than that CISC? Of course not.
A more useful distinction is perhaps "death to microcode". If you have an AES instruction, that is implemented with microcode running on the "normal" ALU's; Yes, CISCy. OTOH, if your chip has hardware for doing AES, adding AES instructions for using that hw doesn't sound particularly "un-RISCy" to me. Then again, many ARM chips apparently microcode some instructions, so meh..
Power9 and ARM both have register renaming and micro-ops. In fact, the SVE extension to ARM provides variable-length vectors, so that the "inner loop" of SIMD compute is stored entirely in micro-code space and independent of the ISA.
ARM-SVE seems very non-RISC to me.
----------
The only thing that seems common to all RISC designs is the load/store architecture, which x86 implements under-the-hood with microops now.
> Power9 and ARM both have register renaming and micro-ops.
And? That's an implementation detail rather than a feature of the ISA. Then again, to some extent so is microcode, so I'm contradicting myself. Ugh. Well anyway, although these days there seems little common ground in what makes a design RISC, CISC, or whatnot, I think you'll be hard pressed to have much support for the idea the reg renaming or micro-ops would be such a defining feature.
> In fact, the SVE extension to ARM provides variable-length vectors, so that the "inner loop" of SIMD compute is stored entirely in micro-code space and independent of the ISA.
Huh? I thought the point was just that the vector width is not a compile-time constant, but rather there's some instructions like "vlmax foo", which calculates max(foo, implementation vector length), and then you use that as the loop increment rather than a compile-time constant.
Not that the "inner loop" is stored in micro-code space (what does that even mean?).
> ARM-SVE seems very non-RISC to me.
To an extent I agree, but I'd say the most un-RISCy thing of SVE is not the variable length but rather the presence of scatter/gather instructions. I mean, in many RISC definitions there's the limit of one memory op per load/store instr., which makes sense as it makes e.g. exception handling much easier. But here with scatter/gather we have memory instructions which not only load/store multiple consecutive values, but potentially load/store a bunch of values all from different pages! If that isn't non-RISC, then what is.
But then again, scatter/gather is awesome for some problems such as sparse matrix calculations. Practicality trumps ideological purity.
A more useful distinction is perhaps "death to microcode". If you have an AES instruction, that is implemented with microcode running on the "normal" ALU's; Yes, CISCy. OTOH, if your chip has hardware for doing AES, adding AES instructions for using that hw doesn't sound particularly "un-RISCy" to me. Then again, many ARM chips apparently microcode some instructions, so meh..