Re: "A diagram of C23 basic types"

On 4/3/2025 7:02 AM, Michael S wrote:

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/
>
>
Alexis.

 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.
 

Not to forget _Binary16, which I use fairly extensively (far more often than _Binary128 in practice).
It can be a very useful format for cases where one has a lot of numbers and their accuracy is not of particular importance.
It can be useful on PC's even in the absence of actual hardware support (and thus needing to convert to/from 'float' or similar).
In my compiler, Binary16 was given the "short float" type.
Would be nice if there were 8-bit formats, but then again, I have ended up with multiple 8-bit FP formats:
   FP8 and FP8S (S.E4.M3, E4.M3.S)
   FP8U (E4.M4)
     FP8U is positive-only.
     Sometimes useful for things like HDR graphics.
   A-Law (S.E3.M4)
     A-Law is unit-range only when used as an FPU type.
     Useful in audio processing and sometimes for niche things,
       Applicable for things like rotation vectors (unit quaternions),
         when the orientation doesn't need that much precision.
       Roughly similar accuracy to 24 bit yaw/pitch/roll,
         at 256 degs per rotation.
     Though, in audio, may also be seen as representing integer values.
       And, in formats like WAV, would be stored XOR'ed with 0xD5.
The 8-bit formats wouldn't make as much sense for standardization in the same way as the other IEEE types, as their use tends to be more niche.
FP8 is the closest to the other IEEE types, but as used tends to differ:
Inf/NaN range is usually absent, with 0x7F/0xFF instead understood in a similar role to Inf but also treated as the largest value;
The zero range is also absent, often with 00 simply special-cased as 0 (as to whether or not subnormals exist depending on implementation).
There is mention of at least some variants of FP8 having NaN and subnormals though.
For FP8U, if used for HDR, one may use Binary16 as the internal working format for calculations, but store the pixel data in FP8U form (say, for HDR RGBA textures; say because 64-bits per pixel for Binary16 is too expensive).
While arguably FP8U isn't great for image quality, accuracy between 0.5 and 1.0 is at least on-par with RGB555.
Though, granted, in my ISA, there is no direct support for computation on the 8-bit formats, they are mostly limited to conversion on load/store (usually with Binary16 vectors as the in-register format).
...