Double precision maths library

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.

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.

" ... 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