From: bc@freeuk.com   
      
   On 24/11/2025 03:39, BGB wrote:   
   > 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.   
      
   There are two kinds of BitInts: those smaller than 64 bits; and those   
   larger than 64 bits, sometimes /much/ larger.   
      
   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.   
      
   But if a _BitInt(17) is rounded up to 32 bits, there's not going to be   
   any saving!   
      
   Here, I wouldn't use the type system at all to define odd-sized fields.   
   C already has bitfields within structs, that can be used to efficiently   
   pack odd-sized data. But they have lots of restrictions, and are not an   
   independent type.   
      
   (In my stuff, I do the same, but with more control. I also have   
   bitfield-operators that work within ordinary integers. And, in one   
   language, arrays of 1/2/4 bits. But again none of these bitfields of   
   sub-byte elements are proper types, although those u1/u2/u4 elements   
   come close.)   
      
      
   > 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.   
      
   I did once have a very nice 128-bit type in my systems language, but it   
   didn't get enough use to be worth supporting. It was awkward to   
   implement too, since each value type took up two registers, or two stack   
   slots (in some cases, one of each!)   
      
   But my scripting language has an arbitrary-precision /decimal/ floating   
   point type, which can also be used for pure integer calculations.   
      
   I think the maximum range is 10**19000000000 (and a matching minimum).   
   Precision is limited only by memory and runtime, but there are usually   
   caps in place otherwise evaluating 1/3 would go on forever.   
      
   This is one is actually more useful and a lot of fun.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)