Hi Eliot,

In trunk Interpreter>>initializePrimitiveTable we currently have:

		(240 primitiveUTCMicrosecondClock)		"was serial port primitive"
		(241 primitiveLocalMicrosecondClock)		"was serial port primitive"

I think these are the primitives that you wanted to have numbered. Please
let me know if I missed some others.

Note - I have never suggested adding #primitiveUtcWithOffset because I cannot
see any performance impact beyond the initial symbol lookups, so I'm quite
happy to leave it as a named primitive.

Dave

On Tue, Apr 07, 2015 at 06:21:19PM -0700, Eliot Miranda wrote:
> Hi David,
> 
>     named primitives have overhead that numbered ones don't.  Given the importance if time prims can we not have the  Cog numbered prims in the interpreter?
> 
> Eliot (phone)
> 
> On Apr 7, 2015, at 6:10 PM, "David T. Lewis" <lewis at mail.msen.com> wrote:
> 
> > On Tue, Apr 07, 2015 at 11:42:21PM +0200, Levente Uzonyi wrote:
> >> On Tue, 7 Apr 2015, David T. Lewis wrote:
> >> 
> >>> I am away and cannot double check the code right now, but the primitives
> >>> should be consistent across Cog and the interpreter VM. There had been
> >>> some confusion due to the early fork between trunk and oscog, but I
> >>> believe that Eliot and I got it sorted out quite a while ago.
> >> 
> >> I can confirm this, but the primitives don't work correctly on the 
> >> Interpreter VM (4.10.2.2614 on linux from squeakvm.org):
> >> 
> >> Time primUTCMicrosecondClock. "==> 2177453298247316"
> >> Time primPosixMicrosecondClockWithOffset. "==> #(519745201 7200)"
> >> DateAndTime now. "==> 2015-04-07T23:30:28.665+01:00"
> >> 
> >> The same with CogVM:
> >> 
> >> Time primUTCMicrosecondClock. "==> 3605895086935548"
> >> Time primPosixMicrosecondClockWithOffset. "==> #(1428442289746346 7200)"
> >> DateAndTime now. "==> 2015-04-07T23:31:32.962+01:00"
> > 
> > Why do you think this is wrong? I suspect that the one hour time zone
> > offset in your image is not in agreement with the three hour offset that
> > your operating system is reporting. The difference in absolute microseconds
> > is due to different origins in the time scale. Eliot's primitive used the
> > Smalltalk epoch UTC as its origin, and mine used Posix. Neither is wrong.
> > 
> >>> 
> >>> These are not necessarily set up as numbered primitives, but the
> >>> implementations are there, and they can be called as named primitives in
> >>> Cog/Spur and interpreter VMs.
> >>> 
> >>> I don't know about the Pharo fork, it's quite possible that things have
> >>> gotten renamed there.
> >> 
> >> The primitives are the same, but the method names in the image are not, 
> >> and the latter is what matters for me. It's a pain to keep code running in 
> >> both branches.
> >> 
> >>> 
> >>> Note, the UTC with offset primitive is important to me because of
> >>> UTCDateAndTime (http://wiki.squeak.org/squeak/6197), which is designed
> >>> around the notion of a single primitive answering UTC time and local
> >>> offset as an atomic call to the VM.
> >> 
> >> It seems like this primitive caches the time zone offset, which is bad 
> >> when there are daylight savings changes (or when the machine goes to a 
> >> different time zone). Here's the current value from a long running image:
> >> 
> >> Time primPosixMicrosecondClockWithOffset. "==> #(1428442620344927 3600)"
> >> 
> >> But the LocalePlugin's primitives seem like they know the truth:
> >> 
> >> Locale current primTimezone. "==> 120"
> >> Locale current primDST. "==> true"
> > 
> > If you are suggesting that the handling of time zones in the various images
> > is less than perfect, then I will be the first to agree with you. But I don't
> > think that the primitives are wrong.
> > 
> > We have this primitive:
> > 
> >  InterpreterPrimitives>>primitiveUtcWithOffset
> >    "Answer an array with UTC microseconds since the Posix epoch and
> >    the current seconds offset from GMT in the local time zone. An empty
> >    two element array may be supplied as a parameter.
> >    This is a named (not numbered) primitive in the null module (ie the VM)"
> > 
> > And the unix platforms sources implement it like this (with ifdefs removed
> > for clarity):
> > 
> >  sqInt sqUnixUtcWithOffset(sqLong *microSeconds, int *offset)
> >  {
> >    struct timeval timeval;
> >    if (gettimeofday(&timeval, NULL) == -1) return -1;
> >    time_t seconds= timeval.tv_sec;
> >    suseconds_t usec= timeval.tv_usec;
> >    *microSeconds= seconds * 1000000 + usec;
> >    *offset= localtime(&seconds)->tm_gmtoff;
> >    return 0;
> >  }
> > 
> > So the operating system is telling you its best estimate of the current time
> > in microseconds since the Posix epoch, as well as the local time zone offset
> > in seconds at the time of the call. This is a single gettimeofday() call to
> > the platform runtime library, which is about as close as we can get to a
> > coherent result on general purpose unix systems.
> > 
> > Dave
> > 
> >