From: david.brown@hesbynett.no   
      
   On 30/11/2025 13:35, Philipp Klaus Krause wrote:   
   > Am 30.11.25 um 12:28 schrieb David Brown:   
   >>>   
   >>> I see two implementation strategies:   
   >>>   
   >>> * Just ignore the values of the padding bits. You don't need to and   
   >>> or anything after arithmetic operations. Makes arithmetic as fast as   
   >>> possible. But you need special handling at comparisons and casts.   
   >>>   
   >>> * Always keep the padding bits in line with the value, i.e. and after   
   >>> arithemetic operations for unsigned, copy value of sign bit for   
   >>> signed. Extra effort at arithmetic operations, but no extra effort at   
   >>> casts and comparisons.   
   >>>   
   >>   
   >> That sounds about right.  It's much the same as the implementation of   
   >> _Bool.  You either ignore the padding bits while doing the   
   >> calculations and filter them out when they later get in the way, or   
   >> you keep them neat and consistent (signed or unsigned extended, as   
   >> appropriate) during calculations and it's all fine for other   
   >> operations.  I have no idea what might be the most efficient choice   
   >> overall - it could vary by application, but I expect implementations   
   >> to have one fixed strategy.   
   >>   
   >   
   > _Bool is a bit different, since it promotes to int, so we don't really   
   > have arithemetic directly on _Bool:   
      
   It is absolutely true that there are no arithmetic operations on   
   _Bool's.  But there are still operations on _Bool that can (on typical   
   processors) be affected by what is in the padding bits - and thus you   
   need to mask these out at some point.  That includes converting the   
   _Bool to an int before arithmetic operations, or comparison with another   
   _Bool.  So the same principle applies.   
      
   > I can definitely see an   
   > implementation going one way for _BitInt, and the other for _Bool.   
   >   
      
   That's entirely possible.  Your choice of when to deal with the padding   
   bits can be when creating or modifying the type, or when using it in an   
   operation (at the assembly / processor level) that can be affected by   
   the padding bits.  The best choice depends on the efficiency of handling   
   padding at these times, and how often "typical" code does these   
   different types of operations.  It is entirely possible that balance is   
   different for _Bool and for various _BitInt sizes, leading to different   
   choices in implementation strategy.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)