Date:	Tue, 30 May 1995 13:26:18 +0500
From:	ld AT netrix DOT com
To:	gantose AT lerc DOT nasa DOT gov
Subject:	Re: Manually calling iret functions
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu

> From djgpp-bounces AT sun DOT soe DOT clarkson DOT edu Tue May 30 12:44 EDT 1995
> X-Sender: gantose AT dinah DOT lerc DOT nasa DOT gov
> Mime-Version: 1.0
> Date: Tue, 30 May 1995 10:59:42 -0400
> To: djgpp AT sun DOT soe DOT clarkson DOT edu
> From: gantose AT lerc DOT nasa DOT gov (Dave Gantose)
> Subject: Re: Manually calling iret functions
> Cc: c-tsai4 AT uiuc DOT edu
> 
> On Mon, 29 May 1995, Joel Hunter wrote:

[snip]

> In the real-mode handler, rm_new8h(), when it is time to update the PC clock
> (i.e. send that 55ms tick), the appropriate counter is reset, and the old
> (real-mode) handler is called with _go32_dpmi_simulate_fcall_iret(&r). But
> in the protected-mode handler, pm_new8h(), when it is time to update the PC
> clock, the counter is reset, but nothing else is done. Why isn't the same
> call made there?

My guess is:
  1. Bug :->.
  2. The p-mode handler is chained into the old p-mode handler, which is
     a call (task ?) gate to the r-mode ISR, which is a real mode
     call back to the r-mode handler. So, when a p-mode interrupt occurs,
     the following things take place:
[pm int] -> [pm hdlr] -> [ticks++] -> [old pm hdlr] -> [drop to rm] ->
[rmcb]   -> [rm hdlr] -> [ticks++]
     And ticks is increased by two every time a pm interrupt occurs. Therefore
     the pm handler does not have to call the old interrupt handler, because
     the rm handler will do that sooner or later.

> I realize that the p-mode handler was installed with
> _go32_dpmi_chain_protected_mode_interrupt_vector() and so the old p-mode
> handler will be called every time, but there isn't any old p-mode timer
> interrupt handler, is there? So wouldn't the clock fail to get updated?

  This is not the best way to do it, because it requires LOTS of mode
switchings. Another way to do it is to use two handler:
  1. A protected mode handler, which does the following:
      a. Increases & checks the tick count.
      b. Use _go32_dpmi... to call the old interrupt.
      c. Do whatever the ISR is supposed to do.
  2. A REAL real mode handler (which runs in real mode) that does:
      a. Keeps the ticks count for both handlers.
      b. Increases & checks the count.
      c. JUMPS to the old, real handler when necessary.
      d. Does some simple task (increases a count, etc.)
  This method will save about 2 mode switches per real mode interrupts.

Hope that helps,
Long.

- Raw text -