[Vm-dev] microsecond timing for GC work

[Eliot Miranda]

On Tue, Jan 19, 2010 at 4:02 AM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Sun, Jan 17, 2010 at 03:57:10PM -0800, John M McIntosh wrote:
> >
> > The attached change set and sq.h enable microsecond timing for GC work.
> > Please review for consideration for VMMaker.
> >
> > I've added a named primitive
> >
> > primitiveMicrosecondClock
> >       "This is a named (not numbered) primitive in the null module (ie
> the VM)"
> >       self export: true.
> >       self pop: 1 thenPush: (self positive64BitIntegerFor: (self
> ioMicroSeconds)).
> >
> >
> > I used the 'sqLong' data type, but we don't seem to have a usqLong type
> to get unsigned long long  ?
> > Since in this case I'd like the 64bit value to be positive only value...
> >
>
> I would not worry too much about using a sqLong here. If you report time
> in microseconds since the Posix epoch, you can go nearly 300 centuries
> before overflowing a 64 bit signed integer.
>
>  bigLong := (2 raisedTo: 63) - 1.
>  biggestMicrosecAsSeconds := bigLong / 1000000.
>  secondsPerYear := 365.25 * 24 * 60 * 60.
>  maxYears := biggestMicrosecAsSeconds / secondsPerYear.
>  lastYear := 1970 + maxYears asInteger ==> 294241
>

Please keep to the Smalltalk epoch (start of the 20th century, 12am January
1 1901).  Then deriving the second clock from the microsecond clock requires
only division, not division and subtraction.  Small point, but keep it as
simple as possible.  i.e. the Smalltalk code for the second clock could read
^self microsecondClock // 1000000, with the VM losing the secondClock
primitive.


> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100119/b895aaaa/attachment.htm