Re: fixed point vs floating point

[vince.delvecchio@see-below.analog.com (Vince Del Vecchio)]

	<mheaney-ya023680002211972146020001@news.ni.net>
Date: 24 Nov 1997 12:10:12 -0500
Message-ID: <nb4wwhymd57.fsf@dejavu.spd.analog.com>
Organization: Analog Devices CPD
Lines: 39
X-Newsreader: Gnus v5.3/Emacs 19.33

mheaney@ni.net (Matthew Heaney) writes:

> Let's change the problem a bit.  What's more expensive: to calculate the
> sine of a fixed point with a binary small, or to calculate the sine of a
> floating point?  What about making the fixed point 32 bits instead of 64 -
> will that make it more efficient?
> 
> That processor Intermetrics is building an Ada compiler for (SHARC, or
> something like that) comes with "fixed point math in hardware."  Will that
> make any difference in efficiency?

The SHARC (and other Analog Devices DSPs) only support fixed-point math
with a fixed binary point.  Specifically, they support
  type Signed_Fixed is delta 2**(-Word_Size + 1) range -1.0 .. 1.0;
and
  type Unsigned_Fixed is delta 2**(-Word_Size) range 0.0 .. 1.0;

where small == delta, upper endpoint is not a member of the type,
and, for Sharc, Word_Size == 32.

The difference from many other processors is that they have operations for
  Signed_Fixed * Signed_Fixed => Signed_Fixed
  Unsigned_Fixed * Unsigned_Fixed => Unsigned_Fixed
where the shifting you need to do is built to the instruction.

For arbitrary smalls, it probably won't be any faster than on other
processors, but if you restricted yourself to certain smalls, it would
be possible to be as efficient as floating-point.  

On the other hand, for the Sharc specifically, there is no fixed point
sin routine in the C runtime library (or the Ada runtime library, for
that matter).  That is mostly because the processor also has floating
point, and I think most people use the floating point.  Fixed point
transcendental operations are much more prevalent on our fixed-point-only
processors.

-Vince Del Vecchio
vince.delvecchio@analog.com
Not speaking for Analog Devices