delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/05/09/09:34:34

Date: Tue, 9 May 1995 07:14:38 +0500
From: ld AT netrix DOT com
To: djgpp AT sun DOT soe DOT clarkson DOT edu, gantose AT lerc DOT nasa DOT gov
Subject: Re: DJGPP hardware interrupt handler - beyond FAQ

> From djgpp-bounces AT sun DOT soe DOT clarkson DOT edu Mon May  8 12:40 EDT 1995
> X-Sender: gantose AT dinah DOT lerc DOT nasa DOT gov
> Mime-Version: 1.0
> Date: Mon, 08 May 1995 11:32:00 -0400
> To: djgpp AT sun DOT soe DOT clarkson DOT edu
> From: gantose AT lerc DOT nasa DOT gov (Dave Gantose)
> Subject: DJGPP hardware interrupt handler - beyond FAQ
> 
> I'm trying to do a serial port interrupt handler application in DJGPP. I
> have read the FAQ about installing my DJGPP function as both a real mode and
> a protected mode int handler using the _go32_dpmi_... functions. Now, I am
> looking at the file serial.c that is part of the source for the Ladybug
> debugger. It seems to show all the things I need to do, but it brings up
> some questions:
> 
> In Ladybug, there are separate int handlers for real vs protected mode. The
> C parts of the functions are identical, but the beginnings and ends are
> different.
> 1) Specifically, both begin with asm("cli"), but then the pm driver also
> pushes several registers and places the value of DS into location 0x107. Why?

  The pm handler do these because it was not installed with a wrapper, which
did all the registers pushing/poping/initializing. All of these asm ()
statements are for performance only.

> 2) At the end of the function, the real mode handler does
> outportb(0x20,0x20), while the p-mode one does it in assembly. Does it matter?
  
  No, but since the pm handler does everything else in assembly, so I use asm
for the in/outportb functions as well.

> 3) The p-mode handler then pops all the stuff it pushed at the start. But I
> notice that neither handler ever does a asm("sti"). Why not?

  An 'iret', which is done by the pm handler and real mode wrapper, pops the
flag, and therefore returns the IF flag to its original state.

> 4) By the way, what's the difference between asm("cli")/asm("sti") and
> disable()/enable()? Is one preferable over the other? Are there times when
> you should not use one or the other?

  The asm () statements will generally save some CPU instructions.

> 5) To install a p-mode handler, the FAQ says to use
> _go32_dpmi_allocate_iret_wrapper(), but Ladybug does not do this. Is it
> because of the extra asm stuff at the start/end of the function?

  The extra asm statements are used in place of the wrapper.

> 6) In Ladybug, when the real mode int handler is installed, a real mode
> handler for int 1C is also installed. That handler function, called
> refresh_uart just resets the UART registers to the values they should have.
> Is this necessary? Do those registers usually get stepped on somehow? Or
> does it have to do with the debugger application itself (so I can ignore it)?

  Ladybug also redirects DOS IO, which didn't care if someone else is using
the COM port or not. That's why it has to reset the COM port every second.
(i.e. You can ignore it.)

> 7) In Ladybug, before installing either the rm or pm handlers, a function
> named write_child() is called. What does this do? Again, does it have to do
> with the debugger itself, so that I can ignore it (I hope)?

  That writes the value of the debugger's DS into the handler, so that the
statement:
  movw $0x107, %ax
becomes
  movw _what_ever_ds_of_the_debugger_is, %ax

Again, that is done by the wrapper if you use one.

Hope that helps,
Long.

- Raw text -


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