From: david.brown@hesbynett.no   
      
   On 29/11/2025 23:41, Waldek Hebisch wrote:   
   > Philipp Klaus Krause  wrote:   
   >> Am 24.11.25 um 13:31 schrieb bart:   
   >>> On 24/11/2025 11:17, David Brown wrote:   
   >>>> On 24/11/2025 01:30, bart wrote:   
   >>>   
   >>>>> Saving memory was mentioned. To achieve that means having bitfields   
   >>>>> that may not start at bit 0 of a byte, and may cross byte- or word-   
   >>>>> boundaries.   
   >>>>>   
   >>>>   
   >>>> No, that is incorrect.   
   >>>>   
   >>>> The proposal mentions saving /space/ as relevant in FPGAs - not   
   >>>> saving / memory/.   
   >>>   
   >>> But I was responding to a suggestion here that one use of _BitInts -   
   >>> presumably for ordinary hardware - was to save memory.   
   >>>   
   >>> That's not going to happen if they are simply rounded up to the next   
   >>> power-of-two type.   
   >>   
   >> SDCC has no padding bytes - a _BitInt(N) uses (N+7)/8 bytes. And for   
   >> SDCC, _BitInt is currently the only way to get adressable integers that   
   >> are not a "power-of-two type".   
   >   
   > But do SDCC support any non-8 bit processor?  I hope that gcc 8-bit   
   > targets will also use minimal number of bytes.   
   >   
      
   The "bit width" of the processor is not particularly important here   
   (it's also not really a well-defined term).   
      
   The three things that matter for the choice of "chunk size" are :   
      
   1. The minimum size of data that can be addresses.  For all SDCC targets   
   (AFAIK), as well as all gcc targets, that is 8-bit bytes.  For some C   
   targets, like some DSP's, it is bigger.   
      
   2. The size for maximum efficiency when working with larger data.  For   
   an 8051 (targeted by SDCC) or an AVR (the only 8-bit gcc target), that's   
   8 bits.  For an x86-64 processor, it would be 64-bit.   
      
   3. How much users of the target are bothered about memory sizes.   
      
   Clearly the chunk size cannot be smaller than the size from issue 1 -   
   thus "unsigned char" will be the minimum.  And there is nothing to be   
   gained by going bigger than the size from issue 2.   
      
   For most devices where you are concerned about saving a byte or two, you   
   typically operate on 8-bit operands anyway, so your chunk size is 8 bits.   
      
   And that's what I'd expect on the AVR too (noting that gcc for the AVR   
   does not yet support _BitInt's, and I don't think clang has a working   
   AVR backend as yet.  At least, it is not on godbolt!).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)