|Q: division vs multiplication firstname.lastname@example.org (1995-03-24)|
|Re: Q: division vs multiplication email@example.com (1995-04-02)|
|Re: Q: division vs multiplication Terje.Mathisen@hda.hydro.com (1995-04-02)|
|Re: Q: division vs multiplication firstname.lastname@example.org (1995-04-02)|
|Re: Q: division vs multiplication email@example.com (1995-04-03)|
|Re: Q: division vs multiplication davidm@Rational.COM (1995-04-03)|
|Re: Q: division vs multiplication firstname.lastname@example.org (1995-04-04)|
|Re: Q: division vs multiplication Terje.Mathisen@hda.hydro.com (1995-04-06)|
|[11 later articles]|
|From:||email@example.com (KPT Ben)|
|Organization:||America Online, Inc. (1-800-827-6364)|
|Date:||Sun, 2 Apr 1995 08:55:49 GMT|
firstname.lastname@example.org (Mr Tomas Hulek) wrote:
[Can one optimize floating division by powers of two into something like a
When using 32-bit integer math on the PowerPC 601, a brute-force divide is
36 cycles; a multiply is 5 cycles, and bitshifts are 1 cycle.
Multiplication and division by powers of two can be done with a single
bitshift instruction on the 601 (two instructions are necessary when
dividing a signed integer by a power of 2).
One would think that doing the same for floating-point numbers would be
just as easy, if not easier: multiplying a floating-point number by 2
merely means adding 1 to its exponent. Unfortunately the PPC architecture
doesn't implement this as an atomic instruction, but you can read the
floating-point value into an integer register and fiddle with the bits if
you really need to (and in some cases it will still be much faster than
using FPU brute-force).
In any case, floating-point double-precision multiply on the 601 takes 2
cycles (throughput), which is not exactly inefficient... so multiplying by
0.5 or 2.0 couldn't be much slower anyway than adding or subtracting
directly to the exponent, even if the hardware supported it. FP divides on
the 601 are still 31 cycles, unfortunately, and there still are those
cases where you just gotta divide...
anyway, hope this answers your question.
Return to the
Search the comp.compilers archives again.