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,193 of 243,242   
   David Brown to Michael S   
   Re: _BitInt(N)   
   27 Nov 25 21:15:53   
   
   From: david.brown@hesbynett.no   
      
   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).   
      
   --- 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