Hi David, Hi Jiuan,

On Thu, Dec 28, 2017 at 8:56 AM, David T. Lewis lewis@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 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.

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@mail.msen.com mailto:lewis@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,

On 28.12.2017, at 20:07, tim Rowledge tim@rowledge.org wrote:

...

On 28-12-2017, at 8:56 AM, David T. Lewis lewis@mail.msen.com wrote: 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; }

As a reminder to fix the ARM part someday, and because I am *so* not going to mess with git right now, here is an extract from https://www.raspberrypi.org/forums/viewtopic.php?t=30821 "RDTSC on ARM” ===================== Issue 1. The use of x86 assembly code. The FFTW project has a whole bunch of equivalents to rdtsc as part of its own profiling code. See https://github.com/vesperix/FFTW-for-AR ... el/cycle.h Replace the errant lines in nbeesrc-jan-10-2013/src/nbee/globals/profiling-functions.c (lines 49-50) with Code: Select all

volatile unsigned cc; static int init = 0; if(!init) { __asm__ __volatile__ ("mcr p15, 0, %0, c9, c12, 2" :: "r"(1<<31)); /* stop the cc */ __asm__ __volatile__ ("mcr p15, 0, %0, c9, c12, 0" :: "r"(5)); /* initialize */ __asm__ __volatile__ ("mcr p15, 0, %0, c9, c12, 1" :: "r"(1<<31)); /* start the cc */ init = 1; } __asm__ __volatile__ ("mrc p15, 0, %0, c9, c13, 0" : "=r"(cc)); return cc; ====================

Looks interesting, but since when is this supported? When I look for the ARM1176JZF-S Docu (aka Raspberry Pi 1), http://infocenter.arm.com/help/topic/com.arm.doc.ddi0290g/Bihbeabc.html the CP15 info (see p15 above) has info on the c9 register, but not with c12 and c13 as second register.

OTOH, from the ARM Cortex-A7 (aka Raspberry Pi 2), the registers _are_ documented as "Performance monitor Control": http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464f/BABFIBHD.html

Do we want to be pi2-above compatible or also below?

Best regards -Tobias

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim All wiyht. Rho sritched mg kegtops awound?