Direct FPU support on the 68060 is likely using many software 6888x instructions through traps for Mandrelbot calculations since most compilers don't avoid the traps (except new unleased vbcc) vs the handicapped IEEE library functions using mostly software also. Or did you use MuRedox for your stats?
No, the mandelbrot computations only use add,sub and multiplication. Thus, MuRedox makes no difference here. The only traps that may occur are due to non-normalized results where the FPU requires some help. IEEE uses the same instructions, but includes software overhead to load the numbers from the CPU registers into the FPU registers and back. While that makes typically no difference (the called function is long, the register ping-pong is short - intuition!) it makes a difference here. The called function is short (a single add, or sub, or mul) and the overhead is large compared to the actual function.
I guess this tells us that less software and more hardware fp usage is probably faster. Direct FPU use probably won't become more common until FPUs are more common. The new fpga processors are not getting them yet. It looks like the IEEE libraries will be around for awhile. Using the IEEE libraries really isn't that bad for non-CPU intensive multi-68k processor distributions, with a FPU.
For your average all-day purpose, it will hardly make any difference, indeed. But for that purpose, you don't need an FPU in first place either.
The IEEE support in vbcc works surprising well. The default vbcc 68k distribution uses IEEE instead of direct floating point. I have compiled my own 68060+FPU version which is significantly faster though.
Do you mean, it uses IEEE for compiling - or IEEE for the running program? The latter is switchable, but the former is pretty critical. To parse floating point constants in C code correctly, you need a *higher* precision than that used for computing in the program (otherwise, you get an additional loss in the compilation phase you want to avoid). For optimizing, you should run in the C compiler exactly the same computations as the code would have performed, so that's not good news either. Gcc has its own math library for emulating various FPUs and math models, and yes - for good compilation and optimization, this is really required.
You shouldn't have to exchange ROMs with the new fpga hardware. Installing a kickstart to a flash slot could be nearly as easy as installing any other file.
True, except that handling of the files or exchanging modules within the kickstart is harder, i.e. the overall user experience is not quite as good for updates. Otherwise, when I remember the Natami here, it booted so fast it made no difference whether it went through another reset or not, so I don't need an updated rom for this machine in first place. Protecting modules can be done easily by MuProtectModules, no need for a ROM actually.
