From: bc@freeuk.com   
      
   On 25/11/2025 16:29, Michael S wrote:   
   > On Tue, 25 Nov 2025 14:57:17 +0000   
   > bart  wrote:   
   >   
   >> 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.   
   >>   
   >>   
   >>   
   >   
   > My example is from real world. Dealing with A-to-D converters. I need   
   > sign extension of that sort quite often.   
      
   OK, I've looked at datasheets for two 12-ADCs. Both had a choice of   
   analog inputs, and in both the digital value was clocked out serially   
   (one with the input channel number as 4 extra bits).   
      
   The first apparently had a pin-selectable signed/unsigned mode; the   
   second didn't mention that, but did mention 000h and FFFh limits which   
   suggest unsigned.   
      
   But in any case, some extra circuitry would be needed to get the 12   
   parallel bits before they can be input via a 16-bit read. Here, you   
   might just tie D11-D15 together, so that a twos complement 12-bit value   
   becomes a 16-bit one.   
      
   Or maybe the CPU has its own serial input pin. The point is, the whole   
   thing is a rather trivial matter, and it can be taken care of in several   
   places.   
      
   I don't know the details in your case, but if BitInt helps you save a   
   couple of lines of code, then fine. Although I don't think this feature   
   would be worth adding just for that purpose.   
      
   (The only ADCs I've used were 4-bit (homemade) and 8-bit, both giving   
   unsigned data in parallel, used for frame-grabbing video circuits so   
   read directly into memory rather than via an explicit memory- or   
   port-read instruction.)   
      
      
      
      
      
      
    > * I don't recollect needing to sign-extend field that does not start   
   at> offset zero,   
      
   So what's in the rest of the 32-bit field, garbage?   
      
      
   > Same for your other points - I don't recollect that I neeed something   
   > like that sufficiently often to ... well... recollect.   
      
   Yours is one of a thousand possible applications. Everyone will have   
   different needs. Maybe someone else will have a 16 or 32-bit value with   
   assorted bitfields of different widths.   
      
   Then maybe C bitfields could be used, but a bigger problem with those is   
   poor control over layout, which is anyway implementation-defined. (Mine   
   of course don't have that problem!)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)