Date: Sun, 1 Feb 1998 19:50:38 +0200 (IST) From: Eli Zaretskii To: Kris Heidenstrom cc: djgpp AT delorie DOT com Subject: Re: High speed timing In-Reply-To: <34D3CC86.EC3B0A26@clear.net.nz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.