Michael wrote (quoting me):
One little addendum to an earlier message. It may actually be false that Fractint uses IEEE math. In some modes, fractint uses 80 bit "IEEE-like" numbers. I'm not an IEEE math expert, but I'm not entirely sure that 80 bit numbers as used in an Intel Floating Point Unit are legal "IEEE" (though they are very "IEEE-like"). Fractal types in fractint that are implemented 100% in assembler use pure 80
you probably meant "64 bit" ??? """""""
Nope, I meant 80 bits. For some fractint fractal types the math is coded in FPU assembler, and really is 80 bits.
In other modes implemented primarily in C, Fractint does an odd mixture - the 64 bit double precision numbers used to implement double types are IEEE, but these are converted to 80 bits briefly when passed to the math coprocessor.
converted by the FPU internally?
Yes.
Intel(-type) Processors IIRC use 80 bit FP numbers for internal calculations and do a conversion back to 64 bit when saving the results to registers.
If by registers, you mean the regular (non-FPU registers) this is correct. However the FPU register stack maintains values in 80 bit form exclusively, and these values CAN be copied to memory intact as 80 bit values. The old Microsoft C compiler we use for Fractint (the last one that supported the medium memory model) has an 80 bit "long double" type. (Support for this disappeared in later compilers). Once I did a huge hack of fractint for Lee Skinner in which I changed nearly all "double" types to "long double" so Lee could squeeze out another couple of orders of magnitude of precision for a very deep zoom (but not quite arbitrary precision) image he was working on. This never became part of the mainstream Fractint because there were a number of broken features, though the functionality Lee needed worked fine. (rest of Michael's interesting note is snipped) Tim