delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/03/01/21:16:02

From: "John S. Fine" <johnfine AT erols DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: HELP! Assembly language dual mode interrupt handler for djgpp program
Date: Mon, 01 Mar 1999 21:07:57 -0500
Lines: 61
Message-ID: <36DB47FD.16E@erols.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990301171051 DOT 24475E-100000 AT is>
Mime-Version: 1.0
X-Trace: 1A9US/OeFJtyjoXoUesss/HJi8/QMa3cEl3LT2QA4DY=
X-Complaints-To: abuse AT rcn DOT com
NNTP-Posting-Date: 2 Mar 1999 02:09:16 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:

> > The interrupts rate is so high (up to 20 kHZ), that I have to
> > install both real mode and protected mode handlers.
> 
> Are you sure?  Did you try to get away with a protected-mode handler
> alone?  (See section 18.11 of the FAQ for some hints.)  The dual RM/PM
> setup is a lot of work (see below), so you want to be sure you actually
> need it before you embark on that journey...

  I haven't tried doing any of this myself yet, but I have read
a few things about it and gotten very confused by the statement
that it is more efficient to have both rather than pmode only.

  Eli seems to be saying that pmode only might be efficient
enough.  (Which I think still implies that both might be more
effitient).  I can't understand why that would be true.

  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.  When a hardware interrupt
occurs in V86 mode, the interrupt gate always takes you to
pmode (I'm assuming task gates aren't used for IRQ's).  So
regardless of whether you were interrupted from V86 mode or
pmode, you get to the same pmode code before any software
choices occur.

  That pmode code is deap inside the kernel of Windows or
some stand-alone DPMI provider (or similar), so it is
certainly possible that the code looks at what was
interrupted and decides whether to try a V86 mode hook or
a pmode hook first depending on what was interrupted, but
that design doesn't sound useful or likely.  Without a
bizare design like that, I would expect it would try the
pmode hook first and there would be no benefit to having
a "real mode" hook as well.

  Since authoritative sources have come to a different
conclusion than I did, I expect there is something about
the way Windows or CWSDPMI or whatever is handling
hooked interrupts, that I don't know.  I am curious
enough about this area, I really would appreciate it if
someone would enlighten me.

  As to the original question of this thread, I assume
you aren't trying to service those 20Khz interrupts in
a DPMI program under Windows.  You are in some lower
overhead environment such as CWSDPMI.  I think CWSDPMI
is unprotected enough that it shouldn't be too hard to
hook directly into the IDT for the desired IRQ.  (If not,
then there is a ring zero version of CWSDPMI, which lets
you do whatever you want).  If you hooked the IDT
directly, then your pmode only service routine has to be
faster than a V86 mode one under all conditions.  I also
expect that figuring out how to hook the IDT directly
should be easier than writing a whole second version of
your service routine (not to mention the code for
allocating and accessing conventional memory).
-- 
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019