Message-ID: <32D204CD.230A@gbrmpa.gov.au>
Date: Tue, 07 Jan 1997 16:09:56 +0800
From: Leath Muller <leathm AT gbrmpa DOT gov DOT au>
Reply-To: leathm AT gbrmpa DOT gov DOT au
Organization: Great Barrier Reef Marine Park Authority
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: Fixed Point (Optimization)
References: <32cd6b2c DOT 4726585 AT nntp DOT southeast DOT net>
	 <01b9bb84$bc3275a0$e2c5b7c7 AT platko DOT ix DOT netcom DOT com>
	 <32cedb2d DOT 17212822 AT ursa DOT smsu DOT edu> <qwbRXBActG0yEwWC AT foobar DOT co DOT uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> 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
> multiplies floating point is ~4-12* faster. Pipelined you get that 12*
> speedup.

This speedup can be effectively used for fmul, fadd and fsub. So if you
are doing enough adds, subs or muls, and you effectively arrange the
instructions, you can do all of these in a cycle...

> 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.

_If_ you can find enough work for the integer unit to do in this time...
:)
 
> Second: in your test the compiler probably replaced you entire loop with
> a single load in the integer code. It could safely work out the final
> value!
> The float version had to actually do the calculations, its not allowed
> optimise away floating point calculations.
 
> Finally: The one thing to never do is mix integer and float operands.
> Float->int conversion are very slow, fpu integer operations are slow.

Well, they aren't that bad... :)  And you can use a cool trick that
Chris
Hecker explains in Game Developer Magazine for converting FP -> INT
really
quickly which helps.

Leathal.