Also no mention of the binary compatibility issues - which `-march` do you compile your code for? On x86 you have a choice of 3. For RISC-V as far as I can tell there are 96 valid targets.
Not to mention that by sticking with simple single purpose instructions you make the CPU easier to teach to students. That is after all one of the goals of RISC-V in addition to creating a good ISA for industry.
Have we learned nothing about why we abandoned CISC in the first place? Those CPUs got riddled with instructions that never got used much.
Yes... if you willing to tolerate ever more complex and slow instruction decoding. This is a very bad tradeoff.
Secondly, AVX-512 alone has a handful of different extensions. There are a bunch of different SSE variants, and similarly instructions are still being added to the VEX prefix (normal AVX).
There is more potentially for getting it wrong with riscv but 64 bit implies a number of extensions too so it's too far off what amd64 originally meant for X86 (e.g. implies SSE2)
> Firstly -march (or similar, e.g. -mcpu in LLVM land) should target a chip not individual instruction sets.
LLVM still uses -march. And no you shouldn't target a specific chip unless you know your code will only run on that chip. That's the whole point I'm making. Sometimes you do know that (in embedded situations) but often you don't. Desktop apps aren't compiled for specific chips.
> Secondly, AVX-512 alone has a handful of different extensions.
Yes but these are generally linear - if an x86 chip supports extension N it will support extension N-1 too. Not true for RISC-V.
As for linearity, the "generally" bit will apply to RISC-V by the time we have real desktop class chips using the ISA. We still can't assume AVX support for most programs, I don't view this as any different to RISC-V extensions. Just this ~year Intel added VEX-coded AI NN acceleration instructions, I assume RISC-V has similar plans.
Time will tell if there's a de facto minimum set of extensions for desktop RISC-V. Let's hope so, but it isn't guaranteed.
Not if you include AMD and Intel cores in that.
There's plenty of cores that don't follow that versioning scheme, and it's not an Intel or AMD construct.