Double precision maths library

(if the Keil tools had supported ANSI C we would hvave been happy)
rather than missing "tools had supported" I think you missed "time to process using a slow 8 bitter".
Alas, that is water under the bridge. If you do a bit of paper calculations, you will see that fixed point with scaling really is not that big a deal.

in most cases you can, simply by knowing possible ranges, scale by fixed values.

If not, there always is the "floating fixed point" method.

let us have a look at x = ((a * b)/c)

you need one variable "fudge" set to zero before the calculation.

here we go (syntaxically incorrect)

if (a > one_half_max)
{
  a /= 2;
  fudge--;
}
if (b > one_half_max)
{
  b /= 2;
  fudge--;
}
temp = a*b
while (temp < one_half_max)
{
  temp *= 2;
  fudge ++;
}
x = temp/c

Hello Erik

Many thanks for he code ideas (gives me food for thought). I am now in the throws of coding functions with double precision floats... handling NaN, zero, +INF & -INF conditions for each variable & combination like +IN+ + -INF seems to take up most of the effort!.

best regards - Paul

I think you missed "time to process using a slow 8 bitter".<p>

Time is not an issue in some applications.

Not having the double datatype is probably just a way not to lead clueless programmers into the temptation of actually using them - which will then make them complain that their stuff does not work (especially when they try to cram heavy double crunching into ISRs).

Hello Christoph

You are right (& all the other contributors to this duscussion)... it is slow doing this on an 8-bitter. I have just started to test my first attempt & adds go from around 30us with floats to 300us for doubles (10 times slower!!). I hadn't expected such a big impact, but I am writing it in C rather than assembler (I thought C was supposed to be just about as fast as assembler!).

Back to the fun of testing...

thanks - Paul.

"I hadn't expected such a big impact..."

Maybe the $5000 is sounding a bit less unreasonable...?

"I thought C was supposed to be just about as fast as assembler!"

That does, of course, depend very largely upon your skill...
And there are some tasks for which 'C' is particularly unsuited - I guess this could well be one of them?

Hello Paul
Many thanks for the offer and I would welcome a copy when you get it all sorted. We are doing polynomial calculations linearising a 24 bit sensor input on some micro balances (scale). Speed is a secondary requirement, well, no requirement at all really, the most important thing is accuracy.
best regards
Dave

Hello David

If you send me your contact details (to paul.bramley@metrosol-ltd.co.uk), I will get in touch & send you the results of my efforts.

Best Regards - Paul

I hadn't expected such a big impact, but I am writing it in C rather than assembler (I thought C was supposed to be just about as fast as assembler!).<p>

This is one of the cases where hand-coded assembler will beat any kind of high-level language (even C) hands down.

Having access to the CPUs overflow- and carry-flag alone will speed up the calculations significantly since it makes checking for these conditions by doing actual comparisons unnecessary.

You can, of course, access these flags in C code ... however, this is an ugly hack at best (when you know exactly what you are doing and double-check the resulting compiler output, since the actual behavior of the compiler is pretty much undefined in this case), but much more likely it is a sure-fire way to make the program a horrible, bug-infested nightmare. (Read: Don't do it unless you're really willing to verify that the compiler output does what you want it to do, and don't expect anyone after you to do any maintenance on the code.)

If you need speed, it might be worth your while to familiarize yourself with '51 assembler (which, due to the simplicity of the CPU, isn't too bad, as you don't have to deal with pipelines and other things that make an assembler programmers life hard on more modern architectures) to optimize your double arithmetic routines.

We are doing polynomial calculations linearising a 24 bit sensor input on some micro balances (scale).

Have you considered (and discarded) other approaches for doing this (e.g. lookup-table with interpolation) ?

"Yes - this one had me perplexed. 10 decades would be enough for me, but since the IEEE format calls for 8 bytes with a 53-bit mantissa (including the assumed leading 1) I don't know why ANSI C only calls for 10 decades."

I don't think ANSI requires IEEE754 to be used. The explanation for the seemingly 'easy' requirements is most likely to avoid making old implementations non-conforming. ANSI have always seem to have adopted a policy of formalising existing popular implementations rather than pushing the boundaries forward.

"Maybe the $5000 is sounding a bit less unreasonable...?"

Have you seen how little of the standard math library you actually get for your $5000?

" ... double-check the resulting compiler output ... "

Of course, by the time you've done that, you might as well have writted it in assembler in the first place! :-0

Unfortunately the hardware was designed when I arrived on the scene so I have to make the best of a bad situation. However, there is not much choice available when one wants a single chip with 24 bit adc, SIO, PIO, I2C and on board programming built in.
As far as $5000 for a library is concerned, it is possible to buy a complete development system with full double floating point 'C' compile for a lot less than this.

Unfortunately the hardware was designed when I arrived on the scene so I have to make the best of a bad situation. However, there is not much choice available when one wants a single chip with 24 bit adc, SIO, PIO, I2C and on board programming built in.
As far as $5000 for a library is concerned, it is possible to buy a complete development system with full double floating point 'C' compile for a lot less than this.

Unfortunately the hardware was designed when I arrived on the scene so I have to make the best of a bad situation. However, there is not much choice available when one wants a single chip with 24 bit adc, SIO, PIO, I2C and on board programming built in.
As far as $5000 for a library is concerned, it is possible to buy a complete development system with full double floating point 'C' compile for a lot less than this.