[Vm-dev] Time primHighResClock truncated to 32 bits in 64 bits VMs.

[Juan Vuletich]

On 12/28/2017 2:06 PM, Eliot Miranda wrote:

Hi Eliot, Hi David,

> Hi David, Hi Jiuan,
>
> On Thu, Dec 28, 2017 at 8:56 AM, David T. Lewis <lewis at mail.msen.com 
> <mailto:lewis at mail.msen.com>> wrote:
>
>
>     On Thu, Dec 28, 2017 at 09:32:46AM -0300, Juan Vuletich wrote:
>     >
>     > Hi Folks,
>     >
>     > In 32 bit Cog VMs, `Time primHighResClock` answers
>     LargePositiveInteger,
>     > presumably up to 64 bits. This would mean a rollover in 167
>     years on a
>     > 3.5GHz machine.
>     >
>     > But on 64 bit Cog and Stack Spur VMs, it answers a SmallInteger
>     that is
>     > truncated to 32 bits. This means a rollover in about one second.
>     >
>     > I guesss this is a bug. Answering a SmallInteger, truncating the
>     CPU 64
>     > bit counter to 60 bits would be ok. I think it makes sense to
>     restrict
>     > answer to SmallInteger to avoid allocation, and a rollover every 41
>     > years is not too much :)
>     >
>     > Thanks,
>     >
>     > --
>     > Juan Vuletich
>     > www.cuis-smalltalk.org <http://www.cuis-smalltalk.org>
>     > https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>     <https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev>
>     > @JuanVuletich
>     >
>     >
>
>     Attached is the #primHighResClock accessor for Squeak/Pharo users.
>
>     I don't see anything obviously wrong with the primitive, although
>     maybe it
>     involves the handling of positive64BitIntegerFor: in the 64-bit VM.
>
>     The primitive is:
>
>
>     primitiveHighResClock
>             "Return the value of the high resolution clock if this
>     system has any. The exact frequency of the high res clock is
>     undefined specifically so that we can use processor dependent
>     instructions (like RDTSC). The only use for the high res clock is
>     for profiling where we can allocate time based on sub-msec
>     resolution of the high res clock. If no high-resolution counter is
>     available, the platform should return zero."
>     <export: true>
>             self pop: 1.
>             self push: (self positive64BitIntegerFor: self
>     ioHighResClock).
>
>
>     And the platform support code does this:
>
>     sqLong
>     ioHighResClock(void)
>     {
>       /* return the value of the high performance counter */
>       sqLong value = 0;
>     #if defined(__GNUC__) && ( defined(i386) || defined(__i386) ||
>     defined(__i386__)  \
>                             || defined(i486) || defined(__i486) ||
>     defined (__i486__) \
>                             || defined(intel) || defined(x86) ||
>     defined(i86pc) )
>         __asm__ __volatile__ ("rdtsc" : "=A"(value));
>     #elif defined(__arm__) && (defined(__ARM_ARCH_6__) ||
>     defined(__ARM_ARCH_7A__))
>             /* tpr - do nothing for now; needs input from eliot to
>     decide further */
>     #else
>     # error "no high res clock defined"
>     #endif
>       return value;
>     }
>
> Ah, OK.  So this is the problem.  This will answer ex on 64-bit 
> systems, which discard the upper 32-bits.  rdtsc loads %edx:%eax with 
> the 64-bit time stamp, but on 64-bits the in-line asm will simply move 
> %eax to %rax. We have to rewrite that in-line assembler to construct 
> %rax correctly from %edx and %eax.
>
>
>
> -- 
> _,,,^..^,,,_
> best, Eliot


Thanks!

Cheers,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171228/e8ba6964/attachment.html>