home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 242,133 of 243,242   
   bart to Michael S   
   Re: _BitInt(N)   
   25 Nov 25 14:57:17   
   
   From: bc@freeuk.com   
      
   On 25/11/2025 12:12, Michael S wrote:   
   > On Tue, 25 Nov 2025 11:38:32 +0000   
   > bart  wrote:   
   >   
   >>   
   >> No, apart from the usual set of 8/16/32/64 bits. I've done 128 bits,   
   >> and played with 1/2/4 bits, but my view is that above this range,   
   >> using exact bit-sizes is the wrong way to go.   
   >>   
   >   
   > Either that or manifestation of your NIH syndrome.   
   > Which explanation do you consider more likely?   
      
   I can invent anything I like. I've looked at such things many times, and   
   came to the conclusion that using types is the wrong approach, certainly   
   for this level of language.   
      
   (Yes, long ago I allowed type denotations such as:   
      
         int*N a          a has N bytes or N*8 bits (from Fortran)   
         int:N b          b has N bits   
      
   Then I realised I was never going to use anything other than some   
   power-of-two size of 8 bits or more, for discrete variables.)   
      
      
   >   
   >> While for odd sizes up to 64 bits, bitfields are more apt than   
   >> employing the type system.   
   >>   
   >   
   > int sign_extend12(unsigned x)   
   > {   
   >    return (_BitInt(12))x;   
   > }   
   >   
   > Nice, is not it?   
      
   By 'bitfields' I mean bitfields within structs, but also bitfield   
   operators whch work on any integer values.   
      
   Bitfields are nearly always unsigned in my projects, so I don't have an   
   exact equivalent to this example.   
      
   But a solution not using types would look like this:   
      
        y := x.[0..11]           # get first 12 bits   
        y := x.[12..23]          # next 12 bits   
      
        x.[24..35] := y          # set next 12 bits (x, y are 64 bits!)   
      
        y := x.[0..i]            # get first i+1 bits   
      
   To optionally interpret a bitfield extraction as signed, I'd need to   
   think up some way of denoting that. For bitfield insertion it doesn't   
   matter.   
      
   Your example is interesting but rather limited; while it does deal with   
   a signed field:   
      
   * That field can only start at bit zero, without extra manipulations   
      
   * The size is fixed at 12 (if you decide to change the field size, or   
      you want it as a constant parameter somewhere, it starts getting   
      awkward)   
      
   * If you are dealing with a range of bitfield sizes, you will need a   
      dedicated function, or somehow enumerate all possibilities using   
      _Generic.   
      
   * It's not clear how bitfield insertion would work, whether you'd still   
      employ a _BitInt type, and/or just revert to those shifts and masks.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca