www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/11/11/16:06:54

Date: Fri, 11 Nov 1994 09:56:41 -0600 (CST)
From: ALAN L HIGHTOWER <alh AT engr DOT engr DOT uark DOT edu>
Subject: Re: A question about writing interrupt handler in gcc
To: Long Doan <ldoan1 AT mason1 DOT gmu DOT edu>
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu


On Fri, 11 Nov 1994, Long Doan wrote:

> On Wed, 9 Nov 1994, ALAN L HIGHTOWER wrote:

> >     I'm using the dpmi chain pm int vector to establish the handler, 
> > and doing nothing more than checking the type of int and calling the 
> > appropriate function.  In the timers case, simply incrementing a var.
> > As far as the functionality of the handler/irq, it works like a charm, 
> > dma transfers are successfully done via an irq driven system, and voice 
> > related functions are performed correctly, its just the response of the 
> > irq or handler itself really lags.   

>   You might want to bypass the _..._chain_interrupt because there is a 
> 'little' overhead involved.

     How else will I change the vector table?  Using irq7 and not 
chaining the previous handler locks the system up cold.

>   <<<reguarding slowness of outportb()>>>

>   Instead of outportb, or whatever, try:
>   asm("movl _portnum, %dx");
>   asm("movl _value, %al");
>   asm("out  %al, %dl");

    Well, this is excatly what is in the source for outportb() minus the 
stack handling due to it being a function call...  Instead of using 
outportb(), I compiled to assembler and rewrote the function using outs 
like illustrated above, but alas, the same result of considerable lag 
over the MSC real mode version was produced.

Thanx fer ya help...

- Raw text -


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