X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f Date: Wed, 28 Feb 2007 22:28:31 -0700 From: Brian Inglis Subject: Re: Final version of gettimeofday() patch In-reply-to: To: DJGPP-workers Message-id: Organization: Systematic Software MIME-version: 1.0 X-Mailer: Forte Agent 1.93/32.576 English (American) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <200703010015 DOT l210FOi6004906 AT envy DOT delorie DOT com> Reply-To: djgpp-workers AT delorie DOT com On Wed, 28 Feb 2007 17:41:23 -0700, Gordon DOT Schumacher AT seagate DOT com wrote: >DJ Delorie wrote on 02/28/2007 05:15:24 PM: > ># > + double secs; ># ># We need to avoid floating point in libc, whenever possible. Could ># this be done with suitably scaled integer math? CLOCKS_PER_SEC is ># scaled by five to make it an integer. > >Hmm... let me ponder that. > >(I'm assuming this is to avoid issues on systems without FPUs?) > >The goal there is to be as precise as possible so as to avoid clock >skew. As you can see that frequency is not a very nice number... >but perhaps working with a long long int we'd have enough precision? > >I'll have to think about that. Can someone please check if this is correct and feasible. The exact clock rate is 7*5*3*10^6/11/2^19 == 105*10^6/88/2^16 Hz. Could we do: typedef unsigned long long int clock_t #define CLOCKS_PER_SEC 1000000 clock() == (rawclock() << 16)*88/105 This would give us a pretty good integer approximation but with unsigned int we get a period of just less than 01:11:35 before clock() overflows. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada