It makes sense to be conservative with a new architecture but new high performance RISC-V cores such as from SiFive[1] are going to meet RVA23. That standard has vector and bit manipulation extensions that could be used to improve performance with a python interpreter. I guess more testing needs to be done to see if raising the bar is useful.
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.
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.
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 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?
Zba would probably give a small boost. Zbb gives a substantial boost to perf for applications that use clz/popc heavily, but I don't think that would apply to python.
We (CPython) currently only have access to RV64GC machines to test on, and so that is the defacto target we can currently support.
Personally, I hope to see RVA23 become the baseline in the future. But that will depend on adoption.
On the packaging side of things, the platform tag is manylinux_X_Y_riscv64. So far that has meant RV64GC. So before we set a baseline of RVA23, we will need to see where the community lands.
RISC-V RVA22 and RVA23 aren't too different in this regard. Each one prescribes which extensions must be supported by the processor. I saw RV64GC mentioned, this is just a shortening of RV64IMAFDC, so I for baseline instructions, M for multiplication and division, A for atomic, F for floating point, D for double precision floating point and C for compressed instructions.
You can have a baseline E profile instead of I (less registers, some other features stripped), but I don't think we will ever see manufactured RV64E core, trough RV32EC cores exist.
(From personal experience, testing Windows aarch64 is a massive PITA, even on GitHub Actions, which all common sense would indicate should have the best aarch64 Windows CI runner story.)
also Andes is public
We've seen test failures like https://github.com/python/cpython/issues/151040
And perf support needs to be tested and merged https://github.com/python/cpython/issues/121201
Overall though, fairly smooth sailing as you say.
The reason RISC-V wasn't already supported is a mix of lacking hardware access for build bots and committers willing to pledge time to support it.
It's the same with WASI integration. Two Junta members already commit to that failed project in order to show presence and activity.
It is a cancel and buzzword driven project.
I don't understand the significance of this announcement in the submission.
That's significant, but tier 3 is still a caveat. Still allowed to break without blocking anything or being fixed as a priority.
Tier1: Windows x64/i686, Linux x64/ARM gcc, Darwin/ARM
Tier2: Linux x64/ARM w/ clang, Windows ARM, WASM, Darwin/x64
Tier3 is a pretty low support level, but tiers 1 and 2 is a pretty short list of major commercial platforms. Also even for developers to fix, availability of e.g. RiscV machines in the cloud to reproduce and fix on is still somewhat limited.
https://learn.microsoft.com/en-us/lifecycle/products/windows...
Tier 3, or no support at all, seems an appropriate designation.
Looks like the most important step towards tier two is mostly about proving the CI infrastructure is reliable (which takes time at tier 3), and have at least two core developers committed to fixing any issues (within 24 hours)
https://www.sifive.com/development-platforms/sifive-bigsky-s...