[Ace-users] [ace-bugs] ACE_OS::gethrtime produces inconsistent results onx86_64 architecture
jwillemsen at remedy.nl
Sat Nov 10 01:13:11 CST 2007
Feel free to handle this. Make sure this is in bugzilla, then we can refer
people to this.
> -----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:
> 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.
> 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).
> J.T. Conklin
More information about the Ace-users