On 27/08/2025 04:51, JJ Marr via Std-Proposals wrote:
> > I know ieee-754 is from 1985 and nearly everyone uses it and thus
> double is for paractial purposes ieee-754, but are we forcing that
>
> Arduino Uno and Atmega-based devices are prominent examples where double
> is a 32 bit float.[1] I believe this is because they do not have a
> 64-bit FPU. Same with avr-gcc.[2] Can we reinterpret_cast double to a
> float32_t on these platforms?
>

Just to clear up a few details here, Arduino is a platform originally
based on ATMega microcontrollers, which are part of the AVR family, and
for which the AVR port of gcc is the most common compiler. These are
all the same thing, not multiple examples. The AVR is an 8-bit
microcontroller with no floating point support at all. Early versions
of avr-gcc did not have support for 64-bit floating point operations
because no one had written the software routines for them - it is hard
to make these efficient on a machine with 8-bit registers and ALU,
without a barrel shifter and on some AVRs, not even an 8-bit multiply
instruction.

Modern avr-gcc has a "-mdouble-bits=" option to choose 32-bit or 64-bit
doubles. With 32-bit doubles, the compiler is not standards conforming
- but if you actually want to calculate with 64-bit floating point
values, then the AVR is almost certainly the wrong microcontroller
family to use.

Even with you have 64-bit doubles, it is not uncommon for
microcontrollers not to be fully IEEE compliant on their floating point.
  That can apply to hardware floating point units and software
libraries. They typically use the same format, but can lack support for
special values, exceptions, etc. Rounding may not be fully conformant
in operations. And there are some older compilers for microcontrollers
where the floating point formats are not IEEE at all (while still being
compatible with the C standards - they typically don't have much C++
support).

Floating point for small microcontrollers is based on what programmers
need for the kind of code that runs on small microcontrollers, rather
than for ensuring reproducible and predictable results across a range of
hardware and software.