From: bc@freeuk.com   
      
   On 27/11/2025 02:32, Waldek Hebisch wrote:   
   > bart  wrote:   
   >>   
   >> This is about a lower-level systems language working with primitive   
   >> machine types, and having access to the underlying bits of those types.   
   >>   
   >> How much more fundamental can you get?   
   >>   
   >> C provides only basic bitwise operators, and you have to do some   
   >> bit-fiddling, while trying to avoid UB, in order to extract or inject   
   >> individual bits or bitfields.   
   >>   
   >> I provide direct indexing ops to get or set any bit or bitfield, which   
   >> is actually a great core feature to have, but for some reason you want   
   >> to downplay it.   
   >>   
   >> You might just admit for once that it is quite neat.   
   >   
   > Yes, it is neat.   
      
   Hmm, perhaps you're being sincere, perhaps not ...   
      
   >> OK, so how would you do a 'reinterpret' cast in C, of a value like 'x+y'?   
   >   
   > #include    
   > #include    
   >   
   > uint64_t   
   > d_to_u(double d) {   
   >      uint64_t tmp;   
   >      memcpy(&tmp, &d, sizeof(tmp));   
   >      return tmp;   
   > }   
   >   
   > int   
   > f_exp(double d) {   
   >     return (d_to_u(d)>>52)&2047;   
   > }   
   >   
   > Using 'gcc -O' I get the following assembly (only code, without   
   > unimportant directives/labels):   
   >   
   > d_to_u:   
   >          movq    %xmm0, %rax   
   >          ret   
   >   
   > f_exp:   
   >          movq    %xmm0, %rax   
   >          shrq    $52, %rax   
   >          andl    $2047, %eax   
   >          ret   
   >   
   > As you can see 'd_to_u' is single computational instruction,   
   > you can not do better given that floating point registers   
   > are distinct from integer registers.  And 'f_exp' looks   
   > optimal assuming lack of "bit extract" or "extract exponent"   
   > instructions.   
   >   
   > Note that you can put both functions above in a header file,   
   > so once you have written few lines above you can use them   
   > in all your C code.  Of course, efficientcy depends on   
   > compiler optimization.   
      
   Yes (that's something I can't rely on).   
      
   These examples are interesting: with a HLL you normally express yourself   
   in a clear manner, and it is the compiler's job to generate the   
   complicated code required to implement what you mean.   
      
   Here it seems to be other way around: it is the programmer who writes   
   the convoluted code, and the compiler turns that into short, clear   
   instructions! Which unfortunately no one will see.   
      
   If I use your functions like this:   
      
        a = f_exp(x + y);   
      
   then once the x+y result is in a register, gcc-O2 generates this inline   
   code for the extraction:   
      
        movq    rax, xmm0   
        shr rax, 52   
        and eax, 2047   
      
      
   If I express it in my language:   
      
       a := int@(x + y).[52..62]   
      
   then my non-optimising compiler generates this (D0 is rax):   
      
        movq      D0,	XMM4   
        shr       D0,	52   
        and       D0,	2047   
      
   So such features have definite advantages, in being able to express   
   intent directly, and to make it easier for a simple compiler to know   
   that intent and help it generate reasonable code without lots of   
   analysis or needing function inlining.   
      
   BTW, your example explicitly writes to memory; David Brown posted a   
   version that didn't do so that I could see. Unless a compound literal is   
   designed to be built in memory? However that version only seemed to work   
   with one compiler.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)