Date: Tue, 08 Nov 1994 16:34:44 -0500 (CDT)
From: Aaron Ucko <UCKO AT VAX1 DOT ROCKHURST DOT EDU>
Subject: Re: clock() problems
To: sandmann AT new-orleans DOT NeoSoft DOT com
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Organization: Rockhurst College; Kansas City, MO

>> > Probably it is more than time for the "powers that be" to confess that
>> > 32 bits is no longer sufficient time resolution when gate speeds are
>> > in femtoseconds and time since the epoch is in decades.
>> > 
>> > A good start would be a structure of two thirty-two bit longs, with the
>> > binary seconds point between them.
>> 
>> gcc supports "long long", which is 64 bits.  If we scale that to
>> microseconds, it's good for about 584942 years.  Is it worth the
>> performance penalty?
>
>I don't think so; think about the compatibility problems with current
>code out there.  Since we don't update the tics nearly that often,
>decreasing the clocks per second constant makes more sense in my mind.
>Would 1/10 ms be enough accuracy, assuming we actually updated the tics
>more often than once each 55ms?

Well, we can always (I think) reprogram the AT real-time-clock to interrupt
once every 122.070 \mu s and hook its interrupt--if something else already
hooked it, it should be easy enough to pass it on periodically.

--- Aaron Ucko (ucko AT vax1 DOT rockhurst DOT edu; finger for PGP public key) -=- httyp!
-=*=-Just because you're paranoid doesn't mean they aren't out to get you.-=*=-
Geek code 2.1 [finger hayden AT vax1 DOT mankato DOT msus DOT edu for explanation]: 
 GCS/M/S d(-) H s g+ p? !au a-- w+ v+ C++(+++)>++++ U-(S+)>++++ P+ L>++ 3(-) 
 E-(----) !N>++ K- W(--) M-(--) V(--) po-(--) Y+(++) t(+) !5 j R G tv--(-) 
 b+++ !D(--) B--(---) e>++++(*) u++(@) h!() f(+) r-(--)>+++ n+(-) y?