Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Thu, 3 Apr 2025 13:06:57 -0500
Organization: A noiseless patient Spider
Lines: 79
Message-ID: <vsmiqs$19tp1$1@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <20250403150210.000020f8@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 03 Apr 2025 20:08:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a7d2e5b2e6e147929ab1679437fac851";
	logging-data="1373985"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/AcZppOziOyUKejorFNHmcvb0v2Y5jwAE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0v2nUEpgr/b2SYhho5hILHds+Bs=
In-Reply-To: <20250403150210.000020f8@yahoo.com>
Content-Language: en-US
Bytes: 4132

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).

....