Re: "A diagram of C23 basic types"

On 4/2/2025 10:43 PM, Janis Papanagnou wrote:

On 02.04.2025 09:32, Kaz Kylheku wrote:

On 2025-04-02, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 02.04.2025 07:59, Alexis 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/

>
A nice overview. - I have questions on some of these types...
>
The _Decimal* types - are these just types with other implicit
encodings, say, BCD encoded, or some such?

>
IEEE 754 defines decimal floating point types now, so that's what
that is about. The spec allows for the significand to be encoded
using Binary Integer Decimal, or to use Densely Packed Decimal.

 Thanks for the hint and keywords. It seems my BCD guess was not far
from what these two IEEE formats actually are.
 Does that now mean that every conforming C23 compiler must support
yet more numeric types, including multiple implementation-versions
of the whole arithmetic functions and operators necessary?
 I wonder why these variants had been introduced.
 In many other languages you have abstractions of numeric types, not
every implicitly encoding variant revealed an the programming level.
 

I guess that is a mystery...
Thus far, my compiler does not support them.
If supported, likely options would be one of:
A, Silently convert them to "long double" or similar whenever possible, and use this format internally (while not fast either, Binary128 is at least slightly faster).
B, Turn every operation into a runtime call, mostly leaving all the heavy lifting up to the C runtime library.
C, Create an internal decimal format more like what .NET uses (groups of 9 digits in 32 bits), and then use this; converting to/from the IEEE form on load/store (from pointers/arrays/structs). Merit here being that the .NET style approach is more viable for handling in a pure software implementation.
Or, some combination...
Pretty much nothing uses _Decimal though, and there isn't really an obvious reason for why or how it would be useful to support it, so for now I am ignoring it...
Better to focus on things that have at least some uses, like, say, giant integer types.
Say:
   "_BitInt(512)"
"Woo, 512 bit integer type..."
Currently, my compiler doesn't directly represent any literals larger than 128 bits though. General handling for larger types is, ironically, to internally convert them into special string literals that essentially Base64 encode the value (using groups of 11 digits to represent each 64-bit chunk). Well, sorta... It is actually handled in a way closer to Base85 than proper Base64, eg, just directly using 0x30..0x6F.
So, internally, a string-literal with a _BitInt type or similar.
It is a little wonky, but basically works, backend can sort it out.
Can note for _BitInt and similar:
   128 bits and less:
     Internally stored by padding to the next power-of-2 size.
     Treated as an exact size.
     Uses native integer ops as appropriate.
   Larger:
     Padded up to a multiple of 128 bits;
     Passed around using memory-objects and references;
       Similar to structs.
     All operations are turned into runtime calls.
Core integer types are 8/16/32/64/128 bits, though 128-bit types are generally handled as register pairs.
Operators:
   +, -:
     Native 8/16/32/64
     Native (optional) or call, 128
   &, |, ^:
     Native 8/16/32/64/128
   <<, >>
     Native, 8/16/32/64
     Native (optional) or Call, 128
   *:
     Native 8/16/32
     Native (optional) or Call, 64
     Call only, 128
   /, %:
     Native (optional) or Call, 8/16/32/64
     Call only, 128
   ...
Where, support for 64 bit multiply, or integer divide (in general) is seen as optional in my ISA.
More basic ALU ops support up to 128 bit in the ISA (though, via paired registers, and the ALU's proper remain 64-bit).
But, IMO, at least 128-bit types are semi-useful...

Janis