Math stuff. Yes, there are new math libraries (again). Two of the math libraries are unfortunately in ROM. mathieeesingbas and mathffp. For reasons beyond me, mathieeesingbas was even initialized during bootstrap, even if it was not needed. This had several bad side effects, such as having a non-FPU version of the library on the 68060 as the library became active before SetPatch, so the 68060.library had to clean up behind it. Another problem was that there were again multiple versions of the same library, i.e. with different build options depending on the target model. Now, there is one unified code per library, and not multiple.

As far as mathffp is concerned, the library run (on purpose) into a division by zero exception in case someone wanted to devide a floating point value by zero. This is, however, not like floating point should work. Instead, it should return INF or -INF. Now, mathffp does not have either, so instead HUGE_VAL or -HUGE_VAL is returned. Then again, mathffp is not very suitable for numerics in first place as it does not have denormalized numbers either. The whole documentation for mathffp was quite opaque, too, as it for example claimed that FFPSub() subtracts one argument from another (so far, so clear), but not which argument from which. For some strange reason, the arguments were documented the wrong way around compared to the IEEE version, causing even more confusion. So this was cleaned up - the documentation namely. The RAM counterpart (mathtrans) was only mildly extended to use a larger Cordic table for log and exp such that results are a bit more precise. Yet, the whole mathffp/trans library collection fails any serious test about numerical stability, so just avoid, avoid, avoid...

mathieeesingbas I already talked about. There is one additional trick the IEEE libraries learned. Similar to "jumpy, the magic timer device" we have now also "jumpy, the magic math libraries": That is, if at some point after initialization of the math libraries the FPU becomes available, the math libraries re-initializes themselves and switch to the FPU code. And vice versa. There is still support for the fpsp.resource which comes with the MuLib libraries, so that did not change.

mathieeesingtrans did not change, except that it was a major headache to compile it, given that the SAS/C compiler actually does not support single precision IEEE math. This is probably the topic of another episode as it required major magic and trickery.

mathieeedoubbas and singbas only changed in so far as they configure the FPU slightly different, namely "extended precision, round to zero". The results of the computation are still the same as the last operation in each call to the math code still implies a rounding to double or single precision, but the advantage of the different rounding mode is that a task can open both libraries simultaneously without a conflict, which was not possible before. You had either to use single or double precision, but could not mix (safely, without much additional trickery). "round to zero" is not a very sophisticated rounding mode, though it fits to the CPU implementation of the math libraries and is hence consistent. Probably not quite ideal, though.

mathieeedoubtrans I do not recall any change.