>> ... Do you really need milliseconds that badly? In my ANSI C
>> version, I used both clock() and time()/difftime(), mostly because one
>> method doesn't seem to work in my Linux install. One way should tell
>> parts of seconds, the other only whole seconds. Either way is "close
>> enough", IMHO (though there are ten bazillion corner cases...

> I had considered that.  Most TAP harnesses (tap runners, TAP comes from the
> perl world) calculate the execution time themselves with resolution in the
> msec range always.  There's 15+ year old code around that'll reprogram the
> PIT to 1kHz resolution and keep the standard 18.2 Hz tick going as well (~5
> msec).  Disappointedly, DJGPP, by default doesn't do any better either with
> its POSIX functions.  Even the DOS does 10 msec resolution via INT 0x21/0x2C

How about uclock? DJGPP uses ca. 1.1 MHz resolution for that,
with a combination of medium frequency timer ticks and the
current count in the timer state to get to full resolution.

typedef unsigned int uint32;

#include "time.h"

uint32 get_ytime (void)
  uclock_t uclock_time; /* DJGPP: 64 bit uint */
  uclock_time = uclock () * (uclock_t) 1000000;
  return (uint32) ( uclock_time / UCLOCKS_PER_SEC ); /* ca. 1.1M */

Not POSIX because it has no nice unit such as microseconds,
but certainly worth using. For even more detail, you can use
the CPU time stamp counter. An example for that can be found
in the source code of my 2004 NEWTRACK eye-tracking software,
in the timer.c file :-)

Regards, Eric

AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
Freedos-user mailing list

Reply via email to