From: Walter Banks on


Tim Wescott wrote:

> Depending on the problem, you may never need to convert. Speed
> differences depend on the processor. Two processors, each offering a
> single-cycle MAC at the same clock rate, are going to be about the same
> speed. But implementing a single-cycle floating point MAC takes a lot
> more hardware than doing the same thing with fixed-point. So -- all
> else being equal -- you can expect the floating point processor to be
> bigger, more costly, and more power-hungry.

Two or three years ago I implemented both fixed and floating point
libraries for some of the processors we support. When we
benchmarked the results in a pure software implementation when the
float and fixed point sizes used the same number of bits i.e.. ieee754 32
bit and a fixed point 8:24 for example the number of execution cycles
for the basic functions were very similar. The trade-off's between float
and fixed point are essentially one of dynamic range vs precision.

Regards,


Walter..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com



From: Tim Wescott on
Walter Banks wrote:
>
> Tim Wescott wrote:
>
>> Depending on the problem, you may never need to convert. Speed
>> differences depend on the processor. Two processors, each offering a
>> single-cycle MAC at the same clock rate, are going to be about the same
>> speed. But implementing a single-cycle floating point MAC takes a lot
>> more hardware than doing the same thing with fixed-point. So -- all
>> else being equal -- you can expect the floating point processor to be
>> bigger, more costly, and more power-hungry.
>
> Two or three years ago I implemented both fixed and floating point
> libraries for some of the processors we support. When we
> benchmarked the results in a pure software implementation when the
> float and fixed point sizes used the same number of bits i.e.. ieee754 32
> bit and a fixed point 8:24 for example the number of execution cycles
> for the basic functions were very similar. The trade-off's between float
> and fixed point are essentially one of dynamic range vs precision.

I believe that the biggest barrier to floating point is if you adhere to
the IEEE standard, which requires a considerable amount of exception
handling. I've never done it, but what I hear is that if you handle all
of the exceptions per the specification, that is when code size (or
logic) gets big.

A DSP that has native fixed point support will do fixed point vector dot
products a _lot_ faster than floating point. Beyond that -- well, it
depends on the processor.

My experience with fixed point on a Motorola MPC860 vs. floating point
was considerably different than yours. I don't remember precisely,
other than the fixed point was way faster. If it wasn't 10:1 it was 50:1.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
From: Vladimir Vassilevsky on


Tim Wescott wrote:


> My experience with fixed point on a Motorola MPC860 vs. floating point
> was considerably different than yours. I don't remember precisely,
> other than the fixed point was way faster. If it wasn't 10:1 it was 50:1.

I tried floating point emulation with AVR, 68HC12, TMS320C28xx,
BlackFin, 8051 and like, getting somewhat 15 times difference in speed
compared to optimized integer math. Nevertheless emulated floating point
appears to be sufficiently fast for many practical applications. IMO the
biggest tradeoff is memory footprint: it is hard to fit a floating point
application in a device smaller then 8K.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
First  |  Prev  | 
Pages: 1 2 3
Prev: Confused with Notation
Next: PWM