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

[J.T. Conklin]

"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