Hacker News Reader

Comment by emmatyping | Hacker News Reader

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.

View on HN

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.

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.

Nope, there are subtle differences between Intel and AMD that make it a Bad Idea to fake the vendor.

There are? We aren't talking about feature bits, and the only known software that checks the vendor are Intel's math libraries.

They are minor but enough to complicate things. For example Intel rejects the SYSCALL instruction outside 64-bit mode.

Huh. A quick google says that's a feature bit and there's also an OS call to turn it on.

I know the RPCS3 (PS3 emulator) encountered some differences in a floating point instruction where Intel and AMD had different precision, causing de-synchronizations in LittleBigPlanet multiplayer.

Could be down to this.

Are you talking about the 8087 transcendental instructions? Which are well known and well-written software doesn't have a problem with it.

Huh, where does the “G” come from in RV64GC?

It is a shorthand for "IMAFD" for RV64.

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.

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.

Reply on news.ycombinator.com