SPCmp

Compares two floating point numbers.

Accepts two floating point numbers and returns the condition codes set to indicate the result of said comparison. Additionally, the integer functional result is returned to indicate the result of said comparison.

fnum1

floating point number.

fnum2

floating point number.

Condition codes set to reflect the following branches:

Integer functional result as:

The return value in the condition codes is REALLY the inverse of the result signalled in D0.

Unlike what former documentations said, this function expects fnum1 in D1 not in D0, and fnum2 in D0, not D1, similar to all other mathffp functions. This has always been like it, and it will not change in the future. Earlier autodocs were incorrect. Note that the ".fd" files are correct, i.e. compiler prototypes are correct.

This has the following consequences: If compared with the IEEE libraries, which expect the first argument in the lower, not higher registers, the result as returned in the condition codes is as if you compare D0 with D1, consistently throughout all math models, including this function, FFP and IEEE math. If you look, however, at the argument position as function call from C, the condition codes are exactly the inverse as one would expect. Luckely, if called explicitly as a C function from C code, the condition codes are not reachable and hence irrelevant.

Because the return value in D0 is the inverse of the condition codes, unlike IEEE math, the return value in D0 reflects the comparison of the first argument with the second (+1 if first argument > second), but because the first argument is in D1, this is the inverse of the IEEE return result if looked at the register allocation, but the same argument if looked at the argument position. Hence, again, if called explicitly from C, the result is consistent with that of of IEEE math, but just because the register allocation is the inverse.