I guess one could lobby for
unix (tm) gettimeofday()
for 3.9
This could even be via a plugin, or FFI call...

mmm let's see mmmm
why the unix code uses this
int ioMSecs(void)
{
   struct timeval now;
   gettimeofday(&now, 0);
   if ((now.tv_usec-= startUpTime.tv_usec) < 0)
     {
       now.tv_usec+= 1000000;
       now.tv_sec-= 1;
     }
   now.tv_sec-= startUpTime.tv_sec;
   return lowResMSecs= (now.tv_usec / 1000 + now.tv_sec * 1000);
}

which implies the same clock as ioSeconds which does
     time_t unixTime;

     unixTime = time(0);
     unixTime += localtime(&unixTime)->tm_gmtoff;
     /* Squeak epoch is Jan 1, 1901.  Unix epoch is Jan 1, 1970: 17 leap  
years
         and 52 non-leap years later than Squeak. */
     return unixTime + ((52*365UL + 17*366UL) * 24*60*60UL);

Also some code to start the millisecond clock from zero at image start  
time, I wonder if that is needed  for anything?

Classic mac os-9 uses an elapsed millisecond clock from Open Transport  
which I benched many years ago as being the fastest
way to get a 64 millisecond counter. This gets turned into a signed  
32bit number which then is & with 536870911
before passing up to the smalltalk caller as a SmallInteger.   
Regardless of how the milliseconds are calculated they get & with  
536870911  as part of the primitive caller logic for the millisecond  
clock.

How many days are in 536870911 is an exercise for the reader.

Earlier classic mac VM used Microseconds() which returns a 64bit again  
always & with 536870911


On Sep 21, 2004, at 7:00 PM, John Pierce wrote:

> On Wed, 22 Sep 2004 03:34:15 +0200, Avi Bryant <avi at beta4.com> wrote:
>>
>> On Sep 22, 2004, at 3:26 AM, John Pierce wrote:
>>
>>>> You don't need to know the max value - you just need to know that it
>>>> has rolled over (and you have to make sure that you check frequently
>>>> enough that you'll catch every rollover).
>>>
>>> The current fix you provided just forks a process at image startup to
>>> calculate the offset at a point in time, but I think you are  
>>> proposing
>>> a process that runs all the time to monitor the rollover, right?   
>>> Boy,
>>> this just sounds "hacky", prone to error, and makes me feel queasy.
>>
>> Yup, I don't like it either.  Don't know of anything else that can be
>> done at the image level though.
>>
>>> I wonder what we could do to get the millisecond info directly from
>>> the system clock?  Is that too far fetched?  Am I just dreaming
>>> here....if so wake me up.....
>>
>> It doesn't seem like it should be a hard thing to do... just need a  
>> new
>> prim.  But it's 3am where I am, so I probably *am* dreaming.
>
> Hmmm.....it is only 10pm here and I start to feel really tired when I
> think about adding a prim to get the system clock with millisecond
> precision.  Maybe if I lay down for a bit the feeling to add a prim
> will go away.
>
> Have you, Avi, ever ventured into this territory -- I must say I am
> quite green in adding prims and would be happy to learn, but I
> wouldn't be very quick at it and I would probably foul it all up.
>
> Regards,
>
> John
>
> --  
> Three failures denote uncommon strength. A weakling has not enough
> grit to fail thrice. -- Minna Thomas Antrim
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===