[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
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.
Main Index |
Thread Index |