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)   
|