<br><br><div class="gmail_quote">On Tue, Jan 19, 2010 at 4:02 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Sun, Jan 17, 2010 at 03:57:10PM -0800, John M McIntosh wrote:<br>
><br>
> The attached change set and sq.h enable microsecond timing for GC work.<br>
> Please review for consideration for VMMaker.<br>
><br>
> I've added a named primitive<br>
><br>
> primitiveMicrosecondClock<br>
> "This is a named (not numbered) primitive in the null module (ie the VM)"<br>
> self export: true.<br>
> self pop: 1 thenPush: (self positive64BitIntegerFor: (self ioMicroSeconds)).<br>
><br>
><br>
> I used the 'sqLong' data type, but we don't seem to have a usqLong type to get unsigned long long ?<br>
> Since in this case I'd like the 64bit value to be positive only value...<br>
><br>
<br>
</div>I would not worry too much about using a sqLong here. If you report time<br>
in microseconds since the Posix epoch, you can go nearly 300 centuries<br>
before overflowing a 64 bit signed integer.<br>
<br>
bigLong := (2 raisedTo: 63) - 1.<br>
biggestMicrosecAsSeconds := bigLong / 1000000.<br>
secondsPerYear := 365.25 * 24 * 60 * 60.<br>
maxYears := biggestMicrosecAsSeconds / secondsPerYear.<br>
lastYear := 1970 + maxYears asInteger ==> 294241<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Dave<br>
<br>
</blockquote></div><br>