How is this different from x86_64 and aarch64? Or even the various Alpha and Mips64 chips.

For example x86_64 has v1, v2, v3 and v4 baselines, this tells you which instructions they support (e.g. v4 has AVX-512, v3 has AVX2, etc.).

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.

The E extension will probably only ever appear in softcores (FPGA) to reduce gate count.

CH32V003 has RV32EC core, for RV64, yes, there is no point.

So is 32bit out of scope? ESP32 devices are increasingly RISC-V but 32bit.

32 bit RISC-V is pretty much limited to microcontrollers. There's no serious projects to create a Linux capable RV32 machine. Only FPGA soft cores and QEMU.

There is micropython, but just from the description, it's a separate project entirely with the same syntax, etc.

> 32 bit RISC-V is pretty much limited to microcontrollers

Hence me explicitly talking about ESP32. I was asking about microcontrollers. I know about micropython. I was asking about CPython.

CPython needs you to also be running an operating system. And while it might be theoretically possible to get a NoMMU Linux running on an ESP32, that's generally not very useful for practical applications compared to micropython or something that's actually designed for a microcontroller.

You can just use QEMU. It has RVA23 support and is probably still faster and easier than using actual machines.

That's plausible. The bigger constraint to defaulting to RVA23 is that users are running on, and building all of their wheels targetting, RV64GC. So unless our users adopt RVA23, it would be unwise to switch.

Great point. But QEMU is no longer faster than real hardware for the latest RISC-V chips.

You are right though that QEMU is probably faster than anything only capable of RV64GC (lacking RVA23). So QEMU would probably be a great option for the CPython team.