[Ace-users] [ace-bugs] ACE_OS::gethrtime produces inconsistent results onx86_64 architecture

[Johnny Willemsen]

Hi JT,

Feel free to handle this. Make sure this is in bugzilla, then we can refer
people to this.

Johnny
 

> -----Original Message-----
> From: J.T. Conklin [mailto:jtc at acorntoolworks.com] 
> Sent: Friday, November 09, 2007 7:22 PM
> To: Ernst, Nathan
> Cc: Johnny Willemsen; ace-bugs at cs.wustl.edu
> Subject: Re: [ace-bugs] ACE_OS::gethrtime produces 
> inconsistent results onx86_64 architecture
> 
> "Ernst, Nathan" <Nathan.Ernst at citadelgroup.com> writes:
> > Regarding the thought that this fix is only from AMD64, I 
> don't believe
> > that is necessarily true.  That the existing code works on 
> x86 to begin
> > with is a coincidence of the register layout.  I don't mean to be
> > pedantic (I am trying more to avoid unnecessary forking of 
> the code),
> > but the proposed fix of explicitly referring to both eax 
> and edx is the
> > correct implementation, according the assembler reference.  
> 
> I think I disagree.  From the gcc manual, the i386's 'A' constraint:
> 
>    `A'
>           Specifies the `a' or `d' registers.  This is 
> primarily useful
>           for 64-bit integer values (when in 32-bit mode) intended to
>           be returned with the `d' register holding the most
>           significant bits and the `a' register holding the least
>           significant bits.
> 
> So:
>         asm volatile ("rdtsc" : "=A" (now) : : "memory");
> 
> Says that rdtsc insn writes %eax and %edx, and (if necessary) to copy
> that to 64 bit integer "now".  Since the next thing we do is return,
> and the ABI also says that 64 bit integers are also returned in %eax
> and %edx, it's more than a coincidence.
> 
> All that being said, your fix is needed for the AMD64.  I thought that
> gcc might be smart enough able to recognize putting the 32 halves back
> together into the 64 bit whole on the 386, so the same code could be 
> used on both x86 and x86_64, but from quick tests it appears 
> to generate
> substantially worse code.  So I think we'll really want two versions.
> 
> Unless Johnny wants to fight me for it, I'll take this on.  Although I
> will caution that using rdtsc has subtle issues, and I'll argue it
> probably should *not* be enabled in any ACE config-*.h or binary ACE
> distribution because the end user/integrator needs to carefully
> consider whether those issues are going to effect their deployment.
> (This may be some of the contraversial aspects Robert alluded to
> earlier in this thread).
> 
>     --jtc
> 
> -- 
> J.T. Conklin
>