4 ms·

Speaking unofficially, opinions my own, etc. We (CPython) currently only have access to RV64GC machines to test on, and so that is the defacto target we can cu

Speaking unofficially, opinions my own, etc. 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.

IshKebab 1mo ago
You can just use QEMU. It has RVA23 support and is probably still faster and easier than using actual machines.
- emmatyping 1mo ago
  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.
- LeFantome 1mo ago
  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.
ccgreg 1mo ago
How is this different from x86_64 and aarch64? Or even the various Alpha and Mips64 chips.
- Marcuss2 1mo ago
  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.
  - cbm-vic-20 1mo ago
    The E extension will probably only ever appear in softcores (FPGA) to reduce gate count.
    - Marcuss2 1mo ago
      CH32V003 has RV32EC core, for RV64, yes, there is no point.
  - ccgreg 1mo ago
    Another aspect of the x86_64 architectural swamp is that Intel deliberately makes their optimized math libraries fail if run on a chip that is not 'INTEL INSIDE'. That block totally ignores cpu feature bits. I've always wondered if virtualization software vendors made everything claim to be INTEL INSIDE, just to avoid this problem.
    - bonzini 1mo ago
      Nope, there are subtle differences between Intel and AMD that make it a Bad Idea to fake the vendor.
      - ccgreg 1mo ago
        There are? We aren't talking about feature bits, and the only known software that checks the vendor are Intel's math libraries.
        bonzini 1mo ago
        They are minor but enough to complicate things. For example Intel rejects the SYSCALL instruction outside 64-bit mode.
        ccgreg 1mo ago
        Huh. A quick google says that's a feature bit and there's also an OS call to turn it on.
jubilanti 1mo ago
So is 32bit out of scope? ESP32 devices are increasingly RISC-V but 32bit.
- 6SixTy 1mo ago
  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.
  - jubilanti 1mo ago
    > 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.
    - gavinsyancey 1mo ago
      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.
6SixTy 1mo ago
[dead]

IshKebab 1mo ago

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

emmatyping 1mo ago
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.
LeFantome 1mo ago
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.

ccgreg 1mo ago

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

Marcuss2 1mo ago
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.
- cbm-vic-20 1mo ago
  The E extension will probably only ever appear in softcores (FPGA) to reduce gate count.
  - Marcuss2 1mo ago
    CH32V003 has RV32EC core, for RV64, yes, there is no point.
- ccgreg 1mo ago
  Another aspect of the x86_64 architectural swamp is that Intel deliberately makes their optimized math libraries fail if run on a chip that is not 'INTEL INSIDE'. That block totally ignores cpu feature bits. I've always wondered if virtualization software vendors made everything claim to be INTEL INSIDE, just to avoid this problem.
  - bonzini 1mo ago
    Nope, there are subtle differences between Intel and AMD that make it a Bad Idea to fake the vendor.
    - ccgreg 1mo ago
      There are? We aren't talking about feature bits, and the only known software that checks the vendor are Intel's math libraries.
      - bonzini 1mo ago
        They are minor but enough to complicate things. For example Intel rejects the SYSCALL instruction outside 64-bit mode.
        ccgreg 1mo ago
        Huh. A quick google says that's a feature bit and there's also an OS call to turn it on.

jubilanti 1mo ago

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

6SixTy 1mo ago
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.
- jubilanti 1mo ago
  > 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.
  - gavinsyancey 1mo ago
    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.

6SixTy 1mo ago

[dead]