Re: "A diagram of C23 basic types"

On 4/28/2025 8:27 AM, Michael S wrote:

On Sun, 27 Apr 2025 12:05:16 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
 

Michael S <already5chosen@yahoo.com> writes:
>

On Wed, 02 Apr 2025 16:59:59 +1100
Alexis <flexibeast@gmail.com> wrote:
 

Thought people here might be interested in this image on Jens
Gustedt's blog, which translates section 6.2.5, "Types", of the C23
standard into a graph of inclusions:
>
   https://gustedt.wordpress.com/2025/03/29/a-diagram-of-c23-basic-types/
 

>
That's a little disappointing.
IMHO, C23 should have added optional types _Binary32, _Binary64,
_Binary128 and _Binary256 that designate their IEEE-754 namesakes.
Plus, a mandatory requirement that if compiler supports any of
IEEE-754 binary types then they have to be accessible by
above-mentioned names.

>
I see where you're coming from,

 I suppose, you know it because you followed my failed attempt to improve
speed and cross-platform consistency of gcc IEEE binary128 arithmetic.
Granted, in this case absence of common name for the type was much
smaller obstacle than general indifference of gcc maintainers.
So, yes, on the "producer" side the problem of absence of common name
was annoying but could be regarded as minor.
 Apart from being a "producer", quite often I am on the other side,
wearing a hat of consumer of extended precision types. When in this
role, I feel that the relative weight of inconsistent type names is
rather significant. I'd guess that it is even more significant for
people whose work, unlike mine, is routinely multi-platform. I would
not be surprised if for many of them it ends up as main reason to
refrain completely from use IEEE binary128 in their software; even when
it causes complications to their work and when the type is
readily available, under different names, on all platforms they care
about.
 

In my compiler, it exists as "long double" (though, in the past, understanding "long double" as an alias for "double" was also done, depending on the ABI rules; ended up moving to Binary128 here after noting that code generally didn't use "long double" lightly, so could be used here without too much undue performance penalty).
Though, there are different conventions:
   Understand "long double" as Binary64 (common in MS tools);
   Understand "long double" as Binary128 (typical in GCC);
   Understand "long double" as Intel 80-bit format;
     Common on older 32-bit x86 compilers.
Also "__float128", which is more explicit.
   __float16  / "short float"
   __float32  / "float"
   __float64  / "double"
   __float128 / "long double"
_Binary128 would also be fine IMO.
   Checks, these names didn't exist in my compiler, added them as well.
   Not like one would be using these names for much else...
There are no scalar types for 8-bit FP formats in my compiler, which for now only really exist as SIMD vector types. Could add if really needed, as they "sorta" exist in converter ops.
Internally, my compiler does all scalar floating point math as Binary64 internally regardless of in-memory format (with the FPU ops only operating on Binary64). Narrower formats were handled initially via converters; though ended up adding optional Load/Store ops with built-in converters for Binary32 and Binary16.
The 8 bit formats would require 2 converters (alongside the load/store op; issue being that there are a comparably larger variety of 8-bit formats):
   S.E4.F3, E4.F4, E4.F3.S, S.E3.F4
     And, S.E3.F4 where max is 1.9375 or 0.96875 (*).
*1: The slight loss of low-order dynamic range, but gain of some "above 1.0" values, helping for unit-range values as now 1.0 is directly representable, and there is some overhead to allow for values slightly outside unit range. This helps to some extent with the accuracy of storing normal vectors and unit quaternions as 8-bit FP.
But, with 8-bit formats, precision is bad enough that one can't address all use cases with a single format.

but I disagree with the suggested
addition;  it simultaneously does too much and not enough.  If
someone wants some capability along these lines, the first step
should be to understand what the underlying need is, and then to
figure out how to accommodate that need.  The addition described
above creates more problems than it solves.

 IMHO, a need for a common name for IEEE binary128 exists for quite some
time. For IEEE binary256 the real need didn't emerge yet. But it will
emerge in the hopefully near future.
 

Probably true...