On Mon, Feb 7, 2022 at 11:06 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.
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
It's 2022. We should just require both NaN and IEEE-754. By the time a system is large enough to build and run CPython, it is exceedingly unlikely that it will not be able to do that. Even if it means software emulation of IEEE-754 floating point on something large yet odd enough not to have a FPU. The places where non-IEEE-754 and non-NaN floating point are likely to exist are in specialized parallelized coprocessor hardware. Not the general purpose CPU running CPython. -gps