Mail Archives: djgpp/1998/02/01/18:29:20
Eli Zaretskii wrote:
> 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.
If you are timing an event by waiting for it to occur and then
reading the timer, they are important. Everything that takes
execution away from the foreground task (and under DOS, this is
just interrupts and wait states inserted by the hardware when
the turbo button is switched off) is important. Take a TSR
screen saver for example, which uses int 8 or int 1Ch to get
execution. When it activates, it might stretch that interrupt
out to hundreds or thousands of microseconds. In the application
we are talking about (measuring time between transmitted and
received audio in sonar), this could be very significant, because
the CPU is not able to watch for the event during that time.
This is made worse by the fact that the extended interrupt time
could occur only occasionally, or cylically, causing apparent
glitches or 'motion' of the time being measured. If the event
triggers an interrupt (e.g. through the -ACK input of the
parallel port) this is still an issue because interrupts may not
be enabled during the time the TSR is doing its thing.
The point I made is that anything that is outside your control
is a possible problem when you are doing accurate timing.
TSRs are especially dangerous because they are often written
by amateurs who don't appreciate the issues involved. DOS
systems are mostly not used in real-time applications so no one
notices how badly behaved some software is.
If you are using an int 8 handler in DJGPP then yes the protected
mode handler gets control first, but for accurate timing it is not
normal to use an int 8 handler because it is unusual to operate
int 8 at faster than about 10 kHz, and 100 microsecond resolution
may not be good enough. For accurate timing it is best to avoid
int 8 (or even disable it altogether) and use the timer registers
to read the time when the event occurs. Even using int 8, the
issues of variable latency still apply.
>> 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.
Anything that extends the amount of time the CPU spends doing things
other than waiting for the event, is relevant. Also, when an
interrupt is used to signal the event to the CPU, any time when the
CPU cannot service interrupts is relevant. It is all latency of one
sort or another.
If the program is calling DOS etc, then the CPU is alternating
between real and protected mode, which firstly increases the
likelihood of interrupt acceptance being delayed, and secondly
makes the actual latency quite variable. For the best performance
using this technique it would be best to avoid mode switches
altogether, by either keeping the CPU in protected mode and using
a protected mode handler, or keeping the CPU in real mode and
using a real mode handler (presumably, without EMM386 installed).
>> 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.
Running any sort of real-time software under Windows of any kind is
asking for trouble. You can't even read the timer count in progress
in a VDM under Windows 95 - the timer hardware is emulated and I've
heard that there is a bug in the emulation :-)
Kris
- Raw text -