-------------------- AmigaOS 3.1.4.(1) project -----------------------

Changes made for V45.2 (5.1.2017)

- FFPCmp and FFPTst where needlessly complex in attempting
  to return the correct flags.

- NOTE WELL: The autodocs about FFPCmp confuses register assignment,
  the logic of the function is horrible. The CPU flags reflect
  the comparison of D0 with D1 (as in: cmp.l d1,d0), though
  the value returned by the function reflects the state of
  the comparison of the first argument by the second, which
  is the comparison of D1 with D0, which is exactly the inverse.

- Reassembled with SAS/C "asm". Not that it gives a better
  result, it just detected a couple of problems.

- Added proper library handling code, allowing mathffp be
  flushed from memory, and also converted to a disk-based
  library in case rom space is short.

- Division by zero run into a divison-by-zero exception. While
  this seems acceptable, it is not a good solution for
  floating point implementations which should leave INF or NAN
  in the result instead. Unfortunately, FFP does not have
  means to represent these, thus HUGE_VAL or -HUGE_VAL is returned
  instead.
  
Changes made for 45.3 (6.1.2017)

- Rounding policy changed a bit, rounding at exact mid-point is no 
  longer a round-up.

- Clarified the documentation, and fixed the register assignment of
  SPCmp, which was just the inverse of the documented order. Note that
  the .fd files were correct and do not require fixing.

- Clarified the order of arguments for SPDiv and SPSub which were as
  unclear as they could be.
  

IMPORTANT NOTE TO IMPLEMENTORS:
The quality of the floating point representation of mathffp is
questionable, and this library *should be avoided* in favour of
the IEEE based math libraries. The numerics of this library has
several serious flaws:

- There is no gradual underflow, i.e. there are no
"denormalized numbers". This means that addition and subtraction
are susceptible to cancelation.

- Rounding policy is somewhat questionable. It is neither the
"round to zero" policy the IEEE libraries use, nor full rounding
with round, guard and sticky bit as recommended by IEEE, but a
"round up" without "round to even", thus rounding errors will tend
to pile up.

As a consequence of questionable rounding, "exp(log(x)*y)" and "x^y"
of mathtrans.library will not give identical results, the former
is (when well-defined) typically 1U too large.

Also, as ffp math does not have the possibility to signal INFs and
NANs, error results are signaled by a V bit set - which is not
detectable from C. Instead, the libraries try to provide "reasonable"
return codes. 1/0 returns HUGE_VAL -1/0 -HUGE_VAL. "log" is
symmetrically extended around zero (probably as an attempt to
return the real part of the complex logarithm). Several other ad-hoc
choices have been made for cases like this.

----------------------- AmigaOS 3.2 project --------------------------

Changes made for V46.1 (4.8.2019):

Bumped to V46 to enable automatic loading on Os 3.2.