[Vm-dev] Re: [squeak-dev] Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

David T. Lewis lewis at mail.msen.com
Thu Apr 14 01:58:08 UTC 2011


On Wed, Apr 13, 2011 at 11:57:32AM -0700, Eliot Miranda wrote:
> On Wed, Apr 13, 2011 at 11:09 AM, David T. Lewis <lewis at mail.msen.com>wrote:
> 
> > On Thu, Apr 07, 2011 at 09:04:41AM +0000, commits at source.squeak.org wrote:
> > >
> > > Andreas Raab uploaded a new version of Kernel to project The Trunk:
> > > http://source.squeak.org/trunk/Kernel-ar.564.mcz
> > >
> > > ==================== Summary ====================
> > >
> > > Name: Kernel-ar.564
> > > Author: ar
> > > Time: 7 April 2011, 11:04:21.248 am
> > > UUID: 32ecb9c9-177a-ce45-9c1c-a3714c801929
> > > Ancestors: Kernel-nice.563
> > >
> > > Fix computation of Time>>milliseconds:since: which would compute
> > incorrect deltas upon clock overflow.
> > >
> > > =============== Diff against Kernel-nice.563 ===============
> > >
> > > Item was added:
> > > + ----- Method: Time class>>millisecondClockMask (in category 'general
> > inquiries') -----
> > > + millisecondClockMask
> > > +     "The VM mask for the max. millisecond clock value.
> > > +     This should be primitive but it ain't so it's copied inline from
> > the Interpreter."
> > > +      ^16r1FFFFFFF!
> > >
> >
> > Agreed, the millisecondClockMask should be available from a primitive.
> > Should I make it so?
> >
> 
> Personally I would much rather see us move to the 64-bit millisecond clock I
> implemented for Cog. This renders the whole clock roll-over issue moot.
> 

Understood, though my question was intended to be about the existing
primitiveMillisecondClock, which will presumably be retained for a
few more years. Andreas committed a fix for a rather nasty bug related
to a constant in the image being out of sync with a constant in the VM.
The method comment noted that "This should be primitive but it ain't"
so I was just offering to add the primitive and update Squeak trunk
to use it when available.

Dave



More information about the Vm-dev mailing list