The AmigaOS does *not* use floating point much. Amigas without an FPU do the few floating point operations in software. However, many modern applications and games use floating point heavily because floating point on modern powerful processors has become cheap with a fast FPU and/or SIMD unit (using direct FPU and SIMD instructions in the code). These applications and games will be anywhere between slow and unusable on a low end processor without any hardware floating point support.
Even the Apollo 68k FPGA core recognizes the need for hardware FPU support and compatibility. Gunnar at first only wanted to create FPGA floating point code for the most important single precision (only) IEEE math library functions as this takes the least amount of FPGA space. The C language uses double precision floating point the most and by default and programs using the 68k FPU directly would need to be trapped or patched on the fly (the same as this cheap embedded PPC CPU). I strongly recommended against this and suggested that it was better to wait until there was space for a better solution. Next, Gunnar wanted to add a SIMD unit instead of the 68k FPU (the x86_64 uses the SIMD unit for floating point). There was no room even for single precision floating point support in the SIMD unit so floating point code (and algorithms) would have to be converted to integer code (which is no small task). Single precision floating point would be added to the SIMD unit when there was room but this was no floating point support at all for now. Once again I strongly recommended against adding an SIMD unit without single precision floating point (the most important IMO). A 68060 compatible FPU with direct FPU support and at least double precision is exactly what compilers and floating point using programs need so I highly recommended this. Gunnar doesn't like FPUs and was worried this would be too slow in FPGA. I figured out how to encode twice as many FPU registers allowing for faster instruction interleaving at his request. I also had a few simple suggestions for enhancements I had learned from working with the vbcc vclib floating point math libraries. It looks like the FPU was finally chosen for compatibility on an old 68k CPU which didn't even start with an FPU. PPC is *more* likely to need and expect an FPU, especially without Altivec. I wouldn't be surprised if the Apollo core with FPU support (in an FPGA) outperforms this hard PPC processor without floating point hardware support for floating point intensive programs. This is with the Apollo core being a fraction of the speed of a hard processor and having a fraction of the floating point performance of a SIMD unit for parallel operations. What developers are going to bother with such weak and incompatible floating point performance as this PPC embedded processor?
I do think in this day and age processors with only scalar FPU support are a little bit pointless. May as well go SIMD FPU or go home. Like you said with X64 mode, scalar FPU isn't even an option, only SIMD is available. For scalar operations you just ignore the high elements of your SIMD registers. They still compute as fast as the scalar FPU would compute them.
I think you can get a ton of mileage out of just a handful of SIMD/FPU instructions - multiply, add, subtract, and enough permute and conversion operations to get your data ready for those appropriate math operations.
Anyway, I think in that sense worrying about current Amiga scalar FPU instruction sets and compatibility/performance might be slightly overblown. If we really want to crunch through a lot of floating point values at some point it might be wise to create or adopt a SIMD FPU instruction set everyone could adopt going forward.
