<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 12/28/2017 2:06 PM, Eliot Miranda wrote:<br>
    <br>
    Hi Eliot, Hi David,<br>
    <br>
    <blockquote
cite="mid:CAC20JE1VQ+d4fZzbbjJcTjex2_7qppYwO_phLGXQZVdht57djQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi David, Hi Jiuan,
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, Dec 28, 2017 at 8:56 AM,
            David T. Lewis <span dir="ltr"><<a
                moz-do-not-send="true" href="mailto:lewis@mail.msen.com"
                target="_blank">lewis@mail.msen.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
              0.8ex; border-left: 1px solid rgb(204, 204, 204);
              padding-left: 1ex;"> <br>
              On Thu, Dec 28, 2017 at 09:32:46AM -0300, Juan Vuletich
              wrote:<br>
              ><br>
              > Hi Folks,<br>
              ><br>
              > In 32 bit Cog VMs, `Time primHighResClock` answers
              LargePositiveInteger,<br>
              > presumably up to 64 bits. This would mean a rollover
              in 167 years on a<br>
              > 3.5GHz machine.<br>
              ><br>
              > But on 64 bit Cog and Stack Spur VMs, it answers a
              SmallInteger that is<br>
              > truncated to 32 bits. This means a rollover in about
              one second.<br>
              ><br>
              > I guesss this is a bug. Answering a SmallInteger,
              truncating the CPU 64<br>
              > bit counter to 60 bits would be ok. I think it makes
              sense to restrict<br>
              > answer to SmallInteger to avoid allocation, and a
              rollover every 41<br>
              > years is not too much :)<br>
              ><br>
              > Thanks,<br>
              ><br>
              > --<br>
              > Juan Vuletich<br>
              > <a moz-do-not-send="true"
                href="http://www.cuis-smalltalk.org" rel="noreferrer"
                target="_blank">www.cuis-smalltalk.org</a><br>
              > <a moz-do-not-send="true"
                href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev"
                rel="noreferrer" target="_blank">https://github.com/Cuis-<wbr>Smalltalk/Cuis-Smalltalk-Dev</a><br>
              > @JuanVuletich<br>
              ><br>
              ><br>
              <br>
              Attached is the #primHighResClock accessor for
              Squeak/Pharo users.<br>
              <br>
              I don't see anything obviously wrong with the primitive,
              although maybe it<br>
              involves the handling of positive64BitIntegerFor: in the
              64-bit VM.<br>
              <br>
              The primitive is:<br>
              <br>
              <br>
              primitiveHighResClock<br>
                      "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."<br>
                      <export: true><br>
                      self pop: 1.<br>
                      self push: (self positive64BitIntegerFor: self
              ioHighResClock).<br>
              <br>
              <br>
              And the platform support code does this:<br>
              <br>
              sqLong<br>
              ioHighResClock(void)<br>
              {<br>
                /* return the value of the high performance counter */<br>
                sqLong value = 0;<br>
              #if defined(__GNUC__) && ( defined(i386) ||
              defined(__i386) || defined(__i386__)  \<br>
                                      || defined(i486) ||
              defined(__i486) || defined (__i486__) \<br>
                                      || defined(intel) || defined(x86)
              || defined(i86pc) )<br>
                  __asm__ __volatile__ ("rdtsc" : "=A"(value));<br>
              #elif defined(__arm__) && (defined(__ARM_ARCH_6__)
              || defined(__ARM_ARCH_7A__))<br>
                      /* tpr - do nothing for now; needs input from
              eliot to decide further */<br>
              #else<br>
              # error "no high res clock defined"<br>
              #endif<br>
                return value;<br>
              }<br>
              <br>
            </blockquote>
            <div> </div>
            <div>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.</div>
          </div>
          <br>
          <br clear="all">
          <div><br>
          </div>
          -- <br>
          <div class="gmail_signature" data-smartmail="gmail_signature">
            <div dir="ltr">
              <div><span style="font-size: small; border-collapse:
                  separate;">
                  <div>_,,,^..^,,,_<br>
                  </div>
                  <div>best, Eliot</div>
                </span></div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    Thanks!<br>
    <br>
    Cheers,<br>
    <pre class="moz-signature" cols="72">-- 
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
@JuanVuletich</pre>
  </body>
</html>