From: cr88192@gmail.com   
      
   On 11/27/2025 2:15 PM, David Brown wrote:   
   > On 27/11/2025 15:02, Michael S wrote:   
   >> On Thu, 27 Nov 2025 14:02:38 +0100   
   >> David Brown  wrote:   
   >>   
   >   
   >>   
   >> MSVC compilers compile your code and produce correct result, but the   
   >> code   
   >> looks less nice:   
   >> 0000000000000000 :   
   >>     0:   f2 0f 11 44 24 08       movsd  %xmm0,0x8(%rsp)   
   >>     6:   48 8b 44 24 08          mov    0x8(%rsp),%rax   
   >>     b:   48 c1 e8 34             shr    $0x34,%rax   
   >>     f:   25 ff 07 00 00          and    $0x7ff,%eax   
   >>    14:   c3                      ret   
   >>   
   >> Although on old AMD processors it is likely faster than nicer code   
   >> generated by gcc and clang. On newer processor gcc code is likely a bit   
   >> better, but the difference is unlikely to be detected by simple   
   >> measurements.   
   >   
   > I think it is unlikely that this version - moving from xmm0 to rax via   
   > memory instead of directly - is faster on any processor.  But I fully   
   > agree that it is unlikely to be a measurable difference in practice.   
   >   
   >>   
   >> Also MSVC compiler does not like your style and produces following   
   >> warning:   
   >> dave_b.c(5): warning C4116: unnamed type definition in parentheses   
   >   
   > Warnings are a matter of taste.  There's nothing wrong with my code, but   
   > it may be against some code styles.   
   >   
   >>   
   >> BTW, I don't like your style either. My preferred code will look   
   >> very similar to the code of Waldek Hebisch except that I'd declare   
   >> d_to_u() static.   
   >> I don't like union trick. Not just in this particular context, but   
   >> generally. memcpy() much cleaner in expressing programmer's intentions.   
   >>   
   >   
   > I particularly don't like using unions in compound literals like this   
   > either - it was just to make a compact demonstration.  I'd write real   
   > code in more re-usable bits with static inline functions.   
   >   
   > I disagree, however, that memcpy() shows intent better.  The intention   
   > is not to copy it to memory - the intention is to access the underlying   
   > bit representation as a different type.  A type-punning union is at   
   > least, if not more, clear for that purpose (IMHO - and judgements of   
   > style and clarity are very much a matter of opinion).   
   >   
      
   FWIW, BGBCC allows:   
      double f;   
      u64 uli;   
      uli=(u64)((__m64)f);   
   And, you can extract an exponent as:   
      uli[62:52]   
   But, this is pretty nonstandard...   
      
      
   Here, "val[hi:lo]" works on pretty much any integer type, with the behavior:   
   If it is a normal integer type, will return a zero-extended value of the   
   same type as the input (so, similar to what shift and mask would do).   
      
   If the input type is a _BitInt or _UBitInt, the result will also be   
   _BitInt or _UBitInt with the same width as the bitfield selector.   
      
   It is possible to select a single bit:   
      uli[63]   
   But, this is only valid for _BitInt and _UBitInt, where if a normal   
   integer type it used here, it makes more sense to assume the user had   
   mistyped something, so "uli[63:63]" would be needed for a single bit   
   extract in this case.   
      
   It is also possible to compose values of _UBitInt and similar, say:   
      _UBitInt(24) rgb24;   
      _UBitInt(16) rgb5;   
      rgb5=(_UBitInt(16)) { 0b0u1, rgb24[23:19], rgb24[15:11], rgb24[7:3] };   
      
   Etc...   
      
   Some of this was partly inspired by Verilog in my case.   
      
   Partial merit in this case is that, beyond just being slightly more   
   concise and readable than a more traditional shifts-and-masks approach,   
   also makes it easier for the compiler to generate more efficient code...   
      
   Though, for this particular scenario, my ISA has a specialized CPU   
   instruction for RGB24 to RGB555 that is faster than manually repacking   
   the bits, so alas...   
      
      
   But, also there are special optional instructions for bitfield moves   
   that would allow the above to be expressed in 3 CPU instructions (vs the   
   11 or so instructions that would be needed with a more traditional   
   approach, or 8 if one gets clever with how they use shifts).   
      
   However, with the syntax, without the special CPU instruction, it can   
   infer the 8-instruction construct, and other similar constructs, it   
   cases where it might have otherwise been too much mental effort for a   
   human programmer (and where inferring this from shifts and masks is also   
   asking too much from the compiler...).   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)