From: "John S. Fine" Newsgroups: comp.os.msdos.djgpp Subject: Re: HELP! Assembly language dual mode interrupt handler for djgpp program Date: Tue, 02 Mar 1999 13:00:07 -0500 Lines: 64 Message-ID: <36DC2727.34F0@erols.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: B6WfIr/dlTaNQBSbStepGIT7SOb4U9ATITSMb0jQHes= X-Complaints-To: abuse AT rcn DOT com NNTP-Posting-Date: 2 Mar 1999 18:01:29 GMT X-Mailer: Mozilla 3.01 (Win95; U) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii wrote: > > When you are running "real mode" code in a DPMI program, > > you are not every actually running in real mode (are you?). > > You are running in V86 mode. > > Not necessarily, it depends on the machine configuration. If you run > DJGPP without any memory manager (no EMM386 or QEMM, no Windows), or with > HIMEM alone, you *are* in real mode. Memory managers usually switch the > CPU to V86. . . . > > That pmode code is deap inside the kernel of Windows or > > some stand-alone DPMI provider (or similar), > > More often it is inside a memory manager, unless you run Windows. I never had that good an understanding of the boundaries between the extender and the DPMI server and the memory manager. If you run CWSDPMI without EMM386, then CWSDPMI is responsible for things that otherwise EMM386 would handle. I think you are saying that CWSDPMI, then uses true real mode for DOS calls, rather than using V86 mode. I think using true real mode is a bad design for many reasons, but if CWSDPMI actually works that way, then I certainly understand why having both real mode and pmode hooks for an interrupt would be needed for *best* performance. If CWSDPMI really uses real mode that way, and I was seting up a system to service 20Hz interrupts in djgpp, I think I would make sure QEMM or EMM386 or something was loaded first. Those certainly have their own overhead, but I think the problems in either servicing the interrupts in real mode, or reflecting them to pmode, would outweigh that overhead. > Interrupt reflection from real (or VM86) mode to protected mode is not > that easy. The mode switch itself eats up a lot of cycles, even from > V86, and there are also other chores, like setting up the stack for the > client etc. What do you mean by "even from V86"? Reflecting an interrupt from real mode to protected mode is a complex software operation; Enough so that it would almost always be a better design to avoid using real mode at all (use V86 instead). Reflecting an interrupt from V86 mode to pmode, is not a software task at all. If a hardware interrupt occurs in V86 mode, the CPU delivers it in pmode. It takes a few extra cycles to read the stack pointer from the TSS and to write extra context on the stack, but that overhead is trivial compared to software controlled switches between pmode and real mode. One of my projects runs mainly in V86 mode on a 50Mhz 486. All interrupts are in pmode and it often sevices interrupts well over 20Khz for sustained periods. On a 486 with a write-through cache, it was very hard (but possible) to get acceptable performance in such conditions. Same speed 486 with a write back cache makes it easy. With a write back cache the hardware mode switches to and from V86 mode don't even make the list of the top twenty places that CPU time is spent (during interrupt servicing at over 20Khz). I assume whoever started this was planning to use a better CPU than my 50Mhz 486, so the mode switches to and from V86 mode can be ignored as a performance factor. -- http://www.erols.com/johnfine/ http://www.geocities.com/SiliconValley/Peaks/8600/