lenz@charly.bl.physik.tu-muenchen.de (Udo Lenz) (10/16/90)
I'm developing a time critical application for an interface card, from which a lot of data is read via assembly 'in ax,dx' commands. When benchmarking the I/O routines on a 20 Mhz 386, I've found out, that the 'in ax,dx' command takes roughly a microsecond longer if I have installed Quarterdesks QEMM memory manager. The same delay appears, if I run it under Windows 3.0 in the 386 mode. My present idea is, that the I/O timing under protected mode is different. I have checked, that the 386 is running in protected mode when using QEMM by testing, that the LSB of the machine status word is set. The assembly reference manual says though, that the timing of the 'in ax,dx' command in protected mode is as fast as in real mode, except if encurring a protection fault. My questions are: What is the reason for the delay in the 'in ax,dx' command when using QEMM? Am I really in protected mode when installing QEMM as a device driver in config.sys? If in protected mode, why do my old assembly routines, which do segment register arithmetic and other dirty things, still run? ------- Udo Lenz Sektion Physik der Universitaet Muenchen Am Coulombwall 1 D-8046 Garching Internet: lenz@charly.bl.physik.tu-muenchen.de Germany Bitnet: lenz@dgablg5p
james@bigtex.cactus.org (James Van Artsdalen) (10/17/90)
In <4925@tuminfo1.lan.informatik.tu-muenchen.dbp.de>, lenz@charly.bl.physik.tu-muenchen.de (Udo Lenz) wrote: > I'm developing a time critical application for an interface card, > from which a lot of data is read via assembly 'in ax,dx' commands. > When benchmarking the I/O routines on a 20 Mhz 386, I've found out, > that the 'in ax,dx' command takes roughly a microsecond longer if I > have installed Quarterdesks QEMM memory manager. [...] > The assembly reference manual says though, that the timing of the > 'in ax,dx' command in protected mode is as fast as in real mode, > except if encurring a protection fault. That's not how I interpret the Intel book. It indicates to me 27 clocks in virtual 8086 mode. > My questions are: > What is the reason for the delay in the 'in ax,dx' command when using > QEMM? Lots of microcode, and I presume a fetch from the I/O permission bitmap. > Am I really in protected mode when installing QEMM as a device driver > in config.sys? Yes. > If in protected mode, why do my old assembly routines, which do segment > register arithmetic and other dirty things, still run? Because you're in virtual 8086 mode. Read the Intel book: virtual 8086 mode can be made to act like real mode, but it's still virtual mode timing. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
hwb@texnix.stgt.sub.org (Harald Boegeholz) (10/18/90)
In article <4925@tuminfo1.lan.informatik.tu-muenchen.dbp.de> lenz@charly.bl.physik.tu-muenchen.de (Udo Lenz) writes: > ... I've found out, > that the 'in ax,dx' command takes roughly a microsecond longer if I > have installed Quarterdesks QEMM memory manager. The same delay > appears, if I run it under Windows 3.0 in the 386 mode. [...] > The assembly reference manual says though, that the timing > of the 'in ax,dx' command in protected mode is as fast as in real mode, > except if encurring a protection fault. Mine says something different: IN AX,DX: 13 clocks in real mode 7/27 clocks in protected mode (depending on CPL/IOPL) ****** 27 clocks in *Virtual 8086 Mode* ************ ("Programming the 80386, John H. Crawford, Patrick P. Gelsinger, SYBEX 1987") > What is the reason for the delay in the 'in ax,dx' command when using > QEMM? see below > Am I really in protected mode when installing QEMM as a device driver > in config.sys? No. You are (i.e., your processor is :-) ) in virtual 8086 mode. > If in protected mode, why do my old assembly routines, which do segment > register arithmetic and other dirty things, still run? Well, you're not, and in virtual 8086 mode all dirty real mode tricks work, as the name suggests. Hope this helps -- Harald Boegeholz (hwb@texnix.stgt.sub.org)