From: Yamaha / XYZZ <scriven AT CS DOT ColoState DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Fixed Point (Optimization)
Date: Thu, 09 Jan 1997 10:17:31 -0700
Organization: XYZZ Software Co.
Lines: 28
Message-ID: <32D5282B.41C6@CS.ColoState.edu>
References: <Pine DOT SGI DOT 3 DOT 93 DOT 970108082917 DOT 19523G-100000 AT gibson DOT eee DOT upd DOT edu DOT ph>
NNTP-Posting-Host: dali.vis.colostate.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Orlando Andico wrote:
> > First: floating point is slower at add and subtracts. If all you ever do
> > is add/sub then integer will be 2* faster *at least*. If you use
> > Divides are slightly faster in fpu but a lot less hassle than fixed
> > point. If you use single precision fpu mode they are always 2* faster.
> > Also its possible to continue issuing integer instructions while a float
> > divide executes. That allows tricks like performing a perspective divide
> > in effectively 1 clk.

> is this true for 486's? or just Pentiums? i'm hacking at some MPEG audio

For 486's, try to avoid floating-point.  The integer math will be much
faster, though you still could do some long floating-point operations at
the same time as a bunch of integer calculations.  Also, on a 486,
multiplies (and especially divides) will always be slow unless you fake
it.

> code (MAPLAY -- UNIX-based really) so that it can run faster on 486's (the
> generic MAPLAY chokes on anything less than a Pentium-60) and I would love
> to learn about quickie speedups of FP code.

Look on my web page if you want opcode/timing listings for 486/Pentiums.


-- Yamaha / XYZZ          "May farce the with be you."
mailto:scriven AT CS DOT ColoState DOT edu          
mailto:scriven AT VIS DOT ColoState DOT edu
http://www.vis.colostate.edu/~scriven/