On Mon, Feb 7, 2022 at 11:02 AM Victor Stinner <vstinner@python.org> wrote:
Hi Mark,
Aha, good, you posted an email to python-dev, good :-) Last days, I was trying to collect more data about this topic, especially find platforms which *don't* support IEEE 754, before posting to python-dev.
Nowadays, outside museums, it's hard to find computers which don't implement IEEE 754.
* Since 1998, IBM S/390 supports IEEE 754. * Compaq/DEC VAX didn't use IEEE 754, but are no longer built since 2000 (you cant still use Python 3.10 if it can be built on it!) * Some Cray computers like Cray SV1 (1998) don't implement IEEE 754, but other Cray computers like Cray T90 (1995) implement IEEE 754.
There are embedded devices with no hardware FPU: in this case, the FPU is implemented in software. I expect it to implement IEEE 754. Is CPython a good target for such small CPUs which have no hardware FPU? MicroPython may better fit their needs.
On the other side, all moderns CPU architectures support IEEE 754: Intel x86, ARM, IBM Power and PowerPC, Compaq/DEC Alpha, HP PA-RISC, Motorola 68xxx and 88xxx, SGI R-xxxx, Sun SPARC.
RISC-V also supports the 2008 IEEE-754 spec: https://riscv.org/technical/specifications/ . -Brett
Sources:
* https://en.wikipedia.org/wiki/Floating-point_arithmetic#IEEE_754:_floating_p... * https://stackoverflow.com/questions/2234468/do-any-real-world-cpus-not-use-i...
On Mon, Feb 7, 2022 at 7:25 PM Mark Dickinson <dickinsm@gmail.com> wrote:
- Should we require the presence of NaNs in order for CPython to build? - Should we require IEEE 754 floating-point for CPython-the-implementation?
In the past, when we deprecated the support for an old platform, we didn't suddenly remove the code. We made sure that it's no longer possible to build on it. So if anyone notices, it's easy to revert (ex: remove the few lines in configure).
Would it make sense to trigger a build error on plaforms which don't support IEEE 754 in Python 3.11, and later decide if it's time to remove the code in in Python 3.12?
Well. If you ask *me*, I'm in favor of removing the code right now. If someone needs to support a platform which doesn't support IEEE 754, the support can be maintained *outside* the Python source code, as external patches or as a Git fork, no?
Honestly, I never got access to any machine which doesn't support IEEE 754 (or nobody told me!).
- Should we require IEEE 754 floating-point for Python-the-language?
Right now, I have no opinion on this question.
Note that on the current main branch there's a Py_NO_NAN macro that builders can define to indicate that NaNs aren't supported, but the Python build is currently broken if Py_NO_NAN is defined (see https://bugs.python.org/issue46656). If the answer to the first question is "No", then we need to fix the build under Py_NO_NAN. That's not a big deal - perhaps a couple of hours of work.
My comment on bpo-46656: "Python uses Py_NAN without "#ifdef Py_NAN" guard since 2008. Building Python with Py_NO_NAN never worked. Nobody reported such build failure in the last 14 years..."
If anyone would try building/using Python on a platform without NAN, I would expect that we would get a bug report or an email. I'm not aware of anything like that, so it seems like nobody uses Python on such platform.
Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PPVBMCKL... Code of Conduct: http://python.org/psf/codeofconduct/