<
[email protected]>,
(e-mail address removed) says...
[ ... ]
Thanks that was useful information. I think I understand that I could apply
this CORDIC algorithm if I can use integer arithmetic ( which is ok).
You can apply CORDIC to floating point as well -- though
it works a bit differently.
Floating point is an integer with a scale factor --
nothing more or less than that. For fixed point, the
scale factor is...fixed. For floating point, you store
the scale factor along with the integer being scaled.
That means a few things are a bit different when you do
math on floating point numbers -- but only a few things.
You're dealing a number of the form 2^N * y. That means
to multiply, you have to add the exponents and multiply
the significands. To divide, you subtract exponents and
divide the significands. Interestingly, addition and
subtraction are almost more complex than multiplication
or division -- you have to normalize the two numbers so
they have the same exponent, and then add or subtract the
significands. (e.g. 1.2e12 + 1.1e10 => 1200e10 + 1.1e10
=> 1201.1e10)
When you're done with whichever operation above, you need
to re-normalize your results (if possible -- if it's not
possible, you'll have to decide whether to support
denormals or not).
If memory serves, CORDIC is mostly matrix multiplication,
which means lots of multiplication and addition but
little or no subtraction or division. I don't believe
that CORDIC in general reduces all multiplications to
powers of two though -- at least IIRC, you have to
restrict the angles you work with to get that.
In fact, the algorithm will eventually run on a special
multiprocessor chip without OS and without a coprocessor,
the investigation was to look at a simulation of the
code written in C and running on a workstation to evaluate
performance, size, pros/cons, etc.
The first thing to consider would be what your processor
supports natively, and what you need for your final
results. If you need a format (e.g. floating point) that
it doesn't support directly, you'll need emulate it on
your own to produce results that really mean much. Using
your compiler's native floating point will tell you
nearly nothing about what emulated floating point on your
target will be like. To emulate the floating point, you
could start with something along this line:
struct FP {
unsigned int exponent : 8;
long significand : 24;
FP(float const &initial);
FP const &operator=(FP const &c);
};
FP operator+(FP const &a, FP const &b);
FP operator-(FP const &a, FP const &b);
FP operator*(FP const &a, FP const &b);
FP operator/(FP const &a, FP const &b);
// quite a few more operators and probably functions
// to provide as well.
This particular format is a reasonable approximation of a
typical single-precision floating point type. Of course,
it'll be up to you to emulate it in a usable fashion. As
a lot of hardware manufacturers have found, doing
floating point at all is hard; doing it well is quite a
bit harder.
Of course, if you're going to do fixed point, the same
basic point applies -- meaningful results will depend
(heavily) upon closely emulating what you're going to do
on your target machine.
