The same problem exists for x86. Is $program built for x86-64 with SSE2? AVX2? AVX512? (I chose those three because they are programmer-visible. Programmers have to use intrinsics to exploit those ISA extensions effectively.)
For RISC-V the questions to ask are similar: Is this built for RVA20? Or RVA23? (The big feature of RVA23 is the Vector extension, again something that is programmer-visible)
Embedded RISC-V programmers will have to ask a lot more questions. But for most programmers the whole fragmentation thing is simply a giant meme repeated ad nauseam.
Intel has done such a good job keeping AVX512 support away from reaching ubiquitous adoption, it's insane. There are so many useful instructions in AVX512 which are just missing from AVX/AVX2 that you can't assume exist, even on modern CPUs, because Intel can't get their shit together.
The core problem was tying instructions to bit width. But I'm actually surprised that they didn't add AVX512 support through double pumped 256-bit operations like AMD did for a while.
People bring this up to every RISC-V discussion but the same could be said for ARM or x86. For which ARM instruction set is built? Does this ARM cpu support integer division instructions, does support arm and thumb instruction encoding, only arm, only thumb, does it have a floating point unit, does it have neon, does it have MMU. Those are still relevant questions for ARM cores.
On x86 situation is even crazier https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html . Some of the more recent CPUs list ~60 optional features. Even if you look just at generic common profiles you have i386, i486, i586, i686, x86-64, x86-64-v2, x86-64-v3, x86-64-v4. Just a single family of vector instructions has 6 different versions for example: SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2. I am not even going to try counting all the variations and optional instructions of AVX512.
On one hand this is an important topic, especially in contexts like which X86-64 profile are the software in Linux distro official repositories targeting.
At the same time no one is bothered by 20 cent ARM mcu not having instructions for atomic memory access, supervisor, SIMD or even floating point.
So if anything RISC-V instruction set optional feature sets are probably better structured and less fragmented (for now) than the current situation with ARM and x86.
If you'd limit yourself to cores implementing the Application profile of ARM (Armv8-A etc), you'd do the same and limit yourself to cores implementing the Application profile of RISC-V (RVA23 etc). In that case, you can assume vector instructions and everything else.
If you don't, you get the exact same kind of question with ARM as with RISC-V. Do you use NEON or with SVE? Or do you conservatively compile without vector instructions at all even though it could possibly result in speed-ups for some loops?
The same problem exists for x86. Is $program built for x86-64 with SSE2? AVX2? AVX512? (I chose those three because they are programmer-visible. Programmers have to use intrinsics to exploit those ISA extensions effectively.)
For RISC-V the questions to ask are similar: Is this built for RVA20? Or RVA23? (The big feature of RVA23 is the Vector extension, again something that is programmer-visible)
Embedded RISC-V programmers will have to ask a lot more questions. But for most programmers the whole fragmentation thing is simply a giant meme repeated ad nauseam.
Intel has done such a good job keeping AVX512 support away from reaching ubiquitous adoption, it's insane. There are so many useful instructions in AVX512 which are just missing from AVX/AVX2 that you can't assume exist, even on modern CPUs, because Intel can't get their shit together.
The core problem was tying instructions to bit width. But I'm actually surprised that they didn't add AVX512 support through double pumped 256-bit operations like AMD did for a while.
People bring this up to every RISC-V discussion but the same could be said for ARM or x86. For which ARM instruction set is built? Does this ARM cpu support integer division instructions, does support arm and thumb instruction encoding, only arm, only thumb, does it have a floating point unit, does it have neon, does it have MMU. Those are still relevant questions for ARM cores. On x86 situation is even crazier https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html . Some of the more recent CPUs list ~60 optional features. Even if you look just at generic common profiles you have i386, i486, i586, i686, x86-64, x86-64-v2, x86-64-v3, x86-64-v4. Just a single family of vector instructions has 6 different versions for example: SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2. I am not even going to try counting all the variations and optional instructions of AVX512.
On one hand this is an important topic, especially in contexts like which X86-64 profile are the software in Linux distro official repositories targeting.
At the same time no one is bothered by 20 cent ARM mcu not having instructions for atomic memory access, supervisor, SIMD or even floating point.
So if anything RISC-V instruction set optional feature sets are probably better structured and less fragmented (for now) than the current situation with ARM and x86.
For AP cores where Python actually runs it’s just “arm8” and pick your incremental version on top.
If you'd limit yourself to cores implementing the Application profile of ARM (Armv8-A etc), you'd do the same and limit yourself to cores implementing the Application profile of RISC-V (RVA23 etc). In that case, you can assume vector instructions and everything else.
If you don't, you get the exact same kind of question with ARM as with RISC-V. Do you use NEON or with SVE? Or do you conservatively compile without vector instructions at all even though it could possibly result in speed-ups for some loops?