Date:	Sun, 1 Feb 1998 19:50:38 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Kris Heidenstrom <kheidens AT clear DOT net DOT nz>
cc:	djgpp AT delorie DOT com
Subject:	Re: High speed timing
In-Reply-To:	<34D3CC86.EC3B0A26@clear.net.nz>
Message-ID:	<Pine.SUN.3.91.980201195020.16390K-100000@is>
MIME-Version:	1.0

On Sun, 1 Feb 1998, Kris Heidenstrom wrote:

> The BIOS int 8
> handler doesn't do too much, but TSRs often hook the interrupt or
> int 1Ch which is called by the BIOS int 8 handler, and TSRs are
> often poorly written.  The nett effect is a gap in execution every
> time a timer tick occurs.

If these TSRs are real-mode programs (as they usually are), they are
mostly of no consequences to DJGPP programs which catch the timer
interrupt, because the protected-mode handler gets control *before*
the real-mode ones.

> With DJGPP (or any protected mode program), there is also the
> overhead of one or more mode switches.  The normal handlers for
> hardware interrupts like the timer tick, keyboard, mouse etc
> are real-mode ones, so if the CPU is in protected mode when the
> interrupt occurs, two mode switches are required.  If you use
> interrupts yourself, more mode switches could be needed.

Once again, this is mostly irrelevant, unless the foreground program
is dwelling a lot in real mode (like if it calls DOS or BIOS
services).  If the foreground code runs mostly in protected mode,
there is no overhead due to mode switches, since your protected-mode
handler is called directly from protected mode.  The mode switch
happens only after the protected-mode handler chains to the previous
one.

> Depending on what other requirements you have for your program,
> you could consider disabling all interrupt sources during the
> timing process.

Some environments, such as Windows, don't really let you do that, so
beware.

- Raw text -