From: cr88192@gmail.com
On 11/23/2025 7:59 AM, bart wrote:
> On 23/11/2025 13:32, Waldek Hebisch wrote:
>> Philipp Klaus Krause wrote:
>>> Am 22.10.25 um 14:45 schrieb Thiago Adams:
>>>>
>>>>
>>>> Is anyone using or planning to use this new C23 feature?
>>>> What could be the motivation?
>>>>
>>>>
>>>
>>> Saving memory by using the smallest multiple-of-8 N that will do.
>>
>> IIUC nothing in the standard says that it is smallest multiple-of-8.
>> Using gcc-15.1 on AMD-64 is get 'sizeof(_BitInt(22))' equal to 4,
>> while the number cound fit in 3 bytes.
>
> The rationale mentions a use-case where there is a custom processor that
> might actually have a 22-bit hardware types.
>
> Implementing such odd-size types on regular 8/16/32/64-bit hardware is
> full of problems if you want to do it without padding (in order to get
> the savings). On even with padding (to get the desired overflow semantics).
>
> Such as working out how pointers to them will work.
>
In BGBCC, for any size <= 256 bits, it is padded to the next power-of-2
size. Although if the size is NPOT, some extra handling exists to
mask/extend it to the requested size.
Sizes larger than 256 are padded to the next multiple of 128 bits.
IIRC, GCC and Clang use smaller padding, but not looked into it.
>
>>> Also
>>> being able to use bit-fields wider than int.
>>
>> For me main gain is reasonably standard syntax for integers bigger
>> that 64 bits.
>
> Standard syntax I guess would be something like int128_t and int256_t.
> Such wider integers tend to be powers of two.
>
> But there are two problems with _BitInt:
>
> * Any odd sizes are allowed, such as _BitInt(391)
>
> * There appears to be no upper limit on size, so _BitInt(2997901) is a
> valid type
>
In BGBCC, there is a hard limit of IIRC 16384 bits.
As an extension, it also allows for very large literals, though
currently literals larger than 128 bits can only use hexadecimal or similar.
This is encoded via suffixes, eg:
I, L, LL, U, UI, UL, ULL: Normal 32/64 bit.
I128, UI128: 128-bit
I256, UI256: 256-bit
other odd sizes map to _BitInt or _UBitInt (unsigned _BitInt).
Larger decimal numbers could be supported, but for now I don't have a
strong need for decimal literals beyond 128 bits.
Implicitly, there is a limit of around 1K bits for literals mostly due
to normal tokens having a limit of 255 characters. Compound string
literals have a higher limit of 4096 (standard) or 65536 (implementation).
Possibly, as a little bit of wonk, internally large literals are
implemented in the compiler on top of Base85 strings.
Where, say, for integer literals:
48 bits or less: Stored directly in compiler-specific tagrefs;
49-64 bits: Encoded via an index into a lookup table.
65-128 bits: Split into a pair of 64-bit chunks as indices into a lookup
table;
129+: String cosplaying as an integer literal.
> So what is the result type of multiplying values of those two types?
>
Typically the max of either input type...
> Integer sizes greater than 1K or 2K bits should use an arbitrary
> precision type (which is how large _BitInts will likely be implemented
> anyway), where the precision is a runtime attribute.
>
Disagree, this would open up a whole big mess.
Can't have this for similar reasons to why one doesn't have
variable-sized structs.
Decided to leave out the whole VLA mess.
Better to just pretend VLAs don't exist.
...
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
