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.
RISC-V is now officially supported by CPython
71–76 of 76 posts
Re: RISC-V is now officially supported by CPython
#72Earlier 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.
Could be down to this.
Re: RISC-V is now officially supported by CPython
#73Odd 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…
Re: RISC-V is now officially supported by CPython
#74Earlier 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?
Re: RISC-V is now officially supported by CPython
#75Earlier 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.
Re: RISC-V is now officially supported by CPython
#76Earlier 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.