From: Spehro Pefhany
Subject: Re: To C or not to C
References: <firstname.lastname@example.org> <01c2b41a$cafe2d80$a893eb41@stupidwin95>
X-Newsreader: Forte Agent 1.92/32.572
Date: Sun, 05 Jan 2003 06:47:13 GMT
NNTP-Posting-Date: Sun, 05 Jan 2003 01:47:13 EST
On Sat, 04 Jan 2003 13:01:24 -0800, the renowned "Kevin G. Rhoads"
>Alan Turing is said to have been strongly opposed to the
>use of floating point math, and felt that scaled fixed point
>was more than adequate for all needs.
Unfortunately, C does not support this natively. The fixed point math
available in C, especially when implemented on an 8-bit processor, is
very inefficient. If you look at the code to do a 16 x 16 bit
multiply, yielding a fractional 16 bit result, it's about 4 times
what it should be in terms of execution time, because you have
to use longs and throw away half the result. The code is bigger
as well, IME, as the runtime routines for longs are not linked in
unless they are needed.
I have one little program that does a whole bunch of < 16 bit
measurements and accumulates them for averaging in a 24 bit variable.
That would be extremely inefficient in C, and in this case, that's
important, so it's done in inline assembly, then the result is
shoved into a volatile int that C can use.
> After all, if you
>did not understand how your numbers would be scaling
>through the intermediate calculations, you would likely
>be throwing precision away, often to the point of getting
Well, you do end up scaling manually, often before and after each
step, so you can look at FP as handling that detail for you by doing
the normalization. As we're generally dealing with 8-bit chunks, the
FP routines may do more work than necessary.
> It is amazing to me how insightful
>this seems when I look at all the posts in comp.lang.fortran
>or sci.math.num-analysis &c where people get meaningless
>results due to ill-advised algorithms and then want quad-precision
>floating point just to save a digit or two of meaningful result.
Yes. Algorithms and the understanding of them is key.
>Floating point is MUCH more convenient AT FIRST,
>but learning to deal wiht scaled fixed point is invaluable
>for things which need to pust the limits, like embedded
>projects often end up doing. YMMV.
There's no excuse for not understanding the numerical stability of
"it's the network..." "The Journey is the reward"
email@example.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com