Joerg Sonnenberger wrote: > I think it is easier to maintain a subport with the special toolchain > option of -msoft-float than it is to keep the in-kernel emulation usable > and even fix the existing issues. I've got two different examples of hardfloat emul vs softfloat by other ports in our tree - MIPS and PowerPC: There's a lot of FPUless MIPS chips around, but our kernel emulation of floating point instructions is fast enough that it's a clear win keeping compatibility with precomplied packages and a single userland. On the PowerPC IBM4xx chips however, FPU emulation was abysmally slow. I don't recall the exact figures, but the awk script that ran as part of genassym during a kernel compile took something like 30 minutes with emulated floating point compared with something like 5 or 15 seconds with -msoft-float. There were two reasons, copyin/copyout for small data (like the 1 word to fetch the current instruction that trapped) had high overheads on 4xx, and awk uses floating point numbers for all internal number representations. That said, it's a little bit of a pain not being able to just grab a pre-compiled binary package of ftp.NetBSD.org (or a soft-float release for that matter). But the userbase for that probably doesn't justify setting it up. And then forgetting to add "-msoft-float" to programs (make configure; vi `find work*/ -name Makefile`; make install) and having everything compile but not work is good value too. (This also reminds me that I've got a patch kicking around to make the target compiler default to using -msoft-float. I should dust that off one day...) My advice would be to test both and then if kernel emulation of FPU instructions is in same ballpark as -msoft-float, don't worry about -msoft-float at all. Cheers, Simon.