Message-ID: <BDD73AE8AEE3EF438E07420C2600E9F65C9151@qtiexch0.qgraph.com>
From: "Sisco, Michael" <mdsisco AT qtiworld DOT com>
To: "'Eli Zaretskii'" <eliz AT is DOT elta DOT co DOT il>
Cc: "Djgpp (E-mail)" <djgpp AT delorie DOT com>
Subject: RE: Fw: uclock() within an interrupt handler
Date: Thu, 19 Sep 2002 07:34:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: djgpp AT delorie DOT com

> > > As you will see from the sources, uclock issues an Int 2Fh call, which

> > > might not be a good idea in an interrupt handler.  I'd suggest to take

> > > that call out of the code and see if that helps.
> > 
> > I specifically checked the source for uclock() and I found no such
interrupt
> > 
> > being issued. Am I missing something?
>
> You are missing the fact that __dpmi_yield issues Int 2Fh.

Ahhhhh, I see. Thanks for the input. Here's what I have done to get around
the problem:

At startup, I spend one second and use uclock() together with the RDTSC
macro (read
time stamp counter) to quite accurately calculate the processor speed. I
then use RDTSC any time I need a precise time within my interrupt handler.
This seems
to work very well (with the added benefit that RDTSC is significantly faster
than
uclock()).

Do you see any problems with this approach?