From: cr88192@gmail.com

On 11/24/2025 7:00 PM, Keith Thompson wrote:
> BGB  writes:
>> On 11/24/2025 8:21 AM, bart wrote:
>>> 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.
>>
>> As noted, as I understand it there is no reason for the storage to be
>> smaller than the next power-of-2 size.
>
> Really?
>
> Rounding up to 8, 16, 32, or the next multiple of 64 bits seems
> reasonable.  Rounding 1025 bits up to 2048 does not (and is not
> the current gcc and llvm/clang implementations do).
>

Granted, I meant for smaller sizes (below 128 bits).

BGBCC rounds larger sizes up to the next multiple of 128 bits.

However, 384 bits is the first size where rounding up to a multiple of
128 bits differs from the next power of 2.


> What advantage does rounding 1025 up to 2048 give you over rounding
> it up to 1088 (17*64)?  It seems to me that the only real difference
> is in how many times a loop has to iterate.
>
> My understanding is that power-of-two sizes lose their advantages
> beyond about 64 or 128 bits.  Am I mistaken?
>
> [...]
>

I mentioned a few messages up that this was not the scheme I am using.

So:
    1..  8 =>   8
    9.. 16 =>  16
   17.. 32 =>  32
   33.. 64 =>  64
   65..128 => 128
  129..256 => 256
  256..384 => 384 (first point of divergence)
  385..512 => 512
  513..640 => 640 (second point of divergence)
  641..768 => 768 (third point of divergence)
  ...

But, alas, reason for keeping small sizes power-of-2 is to optimize for
memory loads/stores.

Reason for multiples of 128 bits for larger sizes was this was the most
efficient option for the target ISA (ans also less complicated for the
support code).

Though, if optimizing for RISC-V, a case could be made for using the
next multiple of 64 bits instead.

...


While theoretically possible, multiples of a smaller size would end up
being a worse option in terms of performance than just "wasting" a few
extra bytes.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)