Re: Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)]

> On Tue, Aug 24, 2010 at 09:43:54AM -0700, Eliot Miranda wrote:
> > Hi David,
> >
> > On Tue, Aug 24, 2010 at 5:24 AM, David T. Lewis <[hidden email]>
> wrote:
> >
> > > Eliot,
> > >
> > > I am afraid that I may have misunderstood your original request
> > > to retract the change.
> > >
> > > I assumed that you were refering to Time class>>primUtcWithOffset
> > > that I had added to trunk (and I did remove that method), but
> > > in rereading your note I think you may have been referring to
> > > the earlier VMMaker updates that introduced the primitives
> > > #primitiveMicrosecondClock and #primitiveUtcWithOffset. In
> > > particular, #primitiveMicrosecondClock seems similar to the
> > > Cog primitives, which include #primitiveUTCMicrosecondClock
> > > and #primitiveLocalMicrosecondClock.
> > >
> > > Apologies for my misunderstanding, but can you please clarify
> > > which methods you were suggesting should be retracted?
> > >
> > >        Interpreter>>primitiveMicrosecondClock
> > >        Interpreter>>primitiveUtcWithOffset
> > >        Time class>>primMicrosecondClock
> > >        Time class>>primUtcWithOffset
> > >
> >
> > If primitiveMicrosecondClock answers 64-bit UTC microseconds since 1901
> this
> > is the same as Cog's primitiveUTCMicrosecondClock and should be retained.
>
> primitiveMicrosecondClock is like primitiveMillisecondClock in that
> it answers a value that rolls over periodically, and it not a measure
> of duration relative to any epoch. The extra precision is of course
> meaningless for any individual call, but apparently is of value when
> taken cumulatively for purposes of profiling. I will have to defer
> to John as to whether it can or should be replaced by
> primitiveUTCMicrosecondClock.
>
> In any case, the meanings of primitiveMicrosecondClock and
> primitiveUTCMicrosecondClock are different, and I should think
> that they could safely coexist as long as we give them detailed
> method comments to explain the time basis for each.
>

> >  It also needs a 64-bit local microseconds since 1901 which would be the
> > same as Cog's primitiveLocalMicrosecondClock and a
> > primitiveSignalAtUTCMicroseconds which is for 64-bit microseconds since
> 1901
> > what primitiveSignalAtMilliseconds is for 30-bit wrapping milliseconds
> > (again see Cog).
>
> OK. And I would see no reason not to add these to the traditional SqueakVM
> as well. If you have specific suggestions as to which of the new Cog
> primitives should go into SqueakVM for consistency, that would help.
> I am assuming that at some point we want the Squeak trunk to start making
> use of the new Cog primitives, and that therefore they should also made
> available in the traditional SqueakVM.
>

>
> > We then need to agree on some primitive numbers or
> > primitive names.  In Cog these three are
> >
> > (240 primitiveUTCMicrosecondClock) "was serial port primitive"
> > (241 primitiveLocalMicrosecondClock) "was serial port primitive"
> > (242 primitiveSignalAtUTCMicroseconds)
> >
> > Cog also has
> > (243 primitiveUpdateTimezone) "primStringtranslatefromtotable"
> >
> > primitiveUpdateTimezone
> > "Update the VMs notion of the current timezone.  The VM sets its notion
> >  of the timezone once at start-up.  If one wants the VM to keep its
> notion
> >  up-to-date arrange to invoke this primitive periodically."
> > self ioUpdateVMTimezone
> >
> > which causes the VM to reevaluate the delta between UTC and local
> > microseconds.
> >
> > With these four one has a non-wrapping synchronised timebase with
> > potentially microsecond resolution that marries well with Squeak's 64-bit
> > integer support.  This approach worked very well for VisualWorks where we
> > got rid of lots of customer problems every 49.7 days (2^32 milliseconds).
> >  There has been some concern expressed about the performance impact of
> long
> > integers but at least in VW that simply wasn't an issue.
> >
>
> At this point, primitiveMicrosecondClock and primitiveUtcWithOffset
> are not numbered primitives, and I see no need for them to be numbered.
> As far as I know, no one else has plans to consume additional primitive
> numbers, so we are following your lead with respect to assigning
> primitive numbers (and I should update the SqueakVM table accordingly).
>