Date:	Sun, 2 Apr 2000 10:42:13 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Kalum Somaratna aka Grendel <kalum AT lintux DOT cx>
cc:	DJ Delorie <djgpp AT delorie DOT com>
Subject:	Re: Allegro and interrupts
In-Reply-To:	<Pine.LNX.4.10.10003300517560.1077-100000@darkstar.grendel.net>
Message-ID:	<Pine.SUN.3.91.1000402103229.9367e-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Thu, 30 Mar 2000, Kalum Somaratna aka Grendel wrote:

> On Wed, 29 Mar 2000 night DOT walker AT tiscalinet DOT it wrote:
> 
> > I must call sin() inside an timer function (i can't use a LUT, would
> > be too inaccurate...) I don't know how can i lock the function code
> > (without knowing the size)
> 
> IMHO the code executed in a timer interrupt function should be as little
> as possible (like setting a flag) and should not hog up too much cpu,
> otherwise the whole system will slow down 
> 
> Slow instructions like sin should IMHO not be used in a interrupt
> function

I fail to see how FSIN could be classified as too slow in this context.
Even on an i486 it takes less than 300 cycles, which is less than 10 
microseconds on a DX-33, 5 usec on DX2-66.

The *real* problem is not with using FSIN, but with using any FP 
instructions at all.  If a hardware interrupt handler does that, it needs 
to save and restore the FPU state (with FNSAVE/FRSTOR instructions), or 
else the foreground program might produce erroneous results, if it also 
uses FP instructions.

The DJGPP wrappers don't save the FPU context (and neither do other DOS 
compilers which support the interrupt keyword, AFAIK), so the handler 
typically must do it.

- Raw text -