Live data from Hacker News

RISC-V is now officially supported by CPython

blog.python.org

71–76 of 76 posts

Re: RISC-V is now officially supported by CPython

#71
post #67
post #65

Earlier quoted context omitted.

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.

Re: RISC-V is now officially supported by CPython

#72
post #64

Earlier quoted context omitted.

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,…

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.

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.

Re: RISC-V is now officially supported by CPython

#73
post #12

Odd they still have i686-pc-windows-msvc as Tier 1 *. Even Microsoft doesn't have any supported 32bit Windows versions anymore, and C extension modules likely follow Linux (where Python doesn't have any no supported i686 triplets in any tier). It would be more modern to demote its Tier and promote aarch64 Windows or wasm32 instead to Tier 1. * https://peps.python.org/pep-0011/#tier-1

Python's tiering has to do with testability and availability thereof, not modernness. In the case of 32-bit Windows, the reason it's still testable is because Windows still ships a 32-bit userspace, even if Windows itself only supports x86-64. (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 runn…

That explains Tier-2 vs Tier-3. Not Tier-1 (where i686-windows is) vs Tier-2. Demanding every commit pass CI is a project decision.

Re: RISC-V is now officially supported by CPython

#74
post #70

Earlier quoted context omitted.

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,…

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

It is a shorthand for "IMAFD" for RV64.

Re: RISC-V is now officially supported by CPython

#75
post #71
post #67

Earlier quoted context omitted.

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.

Re: RISC-V is now officially supported by CPython

#76
post #64

Earlier quoted context omitted.

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.

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.
Post reply on HN