From: bc@freeuk.com
On 24/11/2025 13:35, Keith Thompson wrote:
> bart writes:
> [...]
>> There are two kinds of BitInts: those smaller than 64 bits; and those
>> larger than 64 bits, sometimes /much/ larger.
>
> As far as I know, the standard makes no such distinction.
*I* am making the distinction. From an implementation point of view (and
assuming 64-bit hardware), they are quite different.
And that leads to different kinds of language features.
If the possibilities above 64 bits were less ambitious (say i128 and
i256), then the concept might be stretched to cover both. But not when
when you can also have i1234567.
It would be having a GETBITS macro, which is not limited to a 1- to
63-bit bitfield of a u64 value, but could return a slice of an
arbitrarily large array.
>
>> I had been responding to the claim that those smaller types save
>> memory, compared to using sizes 8/16/32 bits which are commonly
>> available and have better hardware support.
>
> I don't recall any such claim. Do you have a citation (other than
> the FPGA-specific wording in N2709)?
This is where it came up in this thread:
On 23/11/2025 11:46, 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. Also
> being able to use bit-fields wider than int.
>
> Saving memory for two reasons:
>
> * On small embedded systems where there is very little memory
> * For code that needs to be very fast on big systems to make data
> structures fit into cache
>
Although this doesn't go as far as using odd bit-sizes: it would mean
using sizes like 24, 40, 48, and 56 bits instead of 32 or 64 bits.
The savings would be sparse.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
