On 28/08/2025 22:06, Tiago Freire via Std-Proposals wrote:
> I would like to point out how unnatural the sentence
>
> "32-bit doubles are, however, more useful on these small microcontrollers"
>
> as if that couldn't just be called a float.
>

Of course it is better to call your types "float" when you want
single-precision floating point. But like it or not, the type "double"
is common in C and C++, and part of the language. So compiling with
"-mdouble-bits=32" means you have write "float x, y; x = y + 3.5;" and
have the calculation done in single precision. The calculation here is
done by first converting the float value of "y" to a double, then using
double-precision addition with the double-precision constant 3.5. It's
very easy to accidentally use double-precision operations even when
trying to restrict yourself to single-precision - so on a device where
double-precision work is so very expensive, making doubles the same
precision as floats is a simple way to avoid mistakes. (gcc also has a
"-Wdouble-promotion" warning that is very helpful.)

In addition, people might want to use pre-written code that uses
"double" types on these devices, keeping the type name unchanged because
they are keeping the code unchanged, but with cheaper operations.

> I'm not saying it's a bad take, it's a view that has been around since
> CPUs have been designed.
> Names don't mean anything, they can just be whatever, to the point that
> we can not clearly express exactly what we mean when we say "double" in
> a language that we use to program.
> This is how people have been doing things for a very long time, but this
> is not normal.
>
> Hence why I think float64_t does wonders in pinning down exactly what we
> mean.
>
> This is not to say that there is no place for wishy-washy types in the
> standard, some algorithms don't require a specific type of float and the
> ability to just get "whatever the hardware happens to support" should be
> expressible.
>
> But there should be an underlying layer of type names that express
> exactly what you get and then the stuff that can just be whatever should
> just be an alias of something deterministically expressed, and the names
> of those types should be reflective of the expectations required of
> those types.
>

I agree with your philosophy here. I am a big user of the <stdint.h>
fixed-size integer types, with occasional use of the "fast" integer
types for some code. But C and C++ come with their history, and it's
far too late to change that now.

For "float" and "double", however, the sizes are almost universally
consistent regardless of the "implementation-defined" leeway given in
the standards. Exceptions like avr-gcc are rare, and you are never in
any doubt when you are using them. Types like "int" and "long" are a
different matter.

> I'm starting to believe that there should be a work group dedicated to
> add hardware specific content to the standard.
> I.e. each cpu architecture should have a library available only to that
> architecture that allows a user do whatever is possible in that
> architecture.
> And then have the rest of the portable standard re-use the arch specific
> components to implement it.
>
>

I am not sure how well that would work, but if you want to expand on
that idea and start a new thread, then I for one would be interested.

Some C folks made a TR for extensions to C for embedded work, TR 18037
<https://www.open-std.org/jtc1/sc22/wg14/www/projects>.

It was, IMHO as an embedded programmer, a total waste of time, and it
never got far. I think the main author might have included some of it
in his own compilers (his company made some expensive but highly
optimising C compilers for some really horrible microcontroller
architectures). gcc also supports some of the fixed point types on some
targets. But they are completely useless to embedded programmers,
because - like "int" - they were all implementation-defined in size.