Hi Warner,
>Without commenting on the need to have an emulator in the kernel,
>doesn't -msoft-float work faster?
Yes it does. The kernel has to emulate an 80x87, giving you the
following sequence:
a) trap to kernel
b) decode FP instruction
c) fetch operands - possibly including copyin()
d) perform operation [this is the only bit the soft-FP code does]
e) store result - possibly including copyout()
f) return from trap
The trap/decode/copyin()/copyout()/rtt are all non-trivial.
> Or is that a MIPS only thing...
It's documented under i386 as well. There is a note that gcc can
still emit some hardware FP instructions (to return FP values on
the 80x87 stack), but this can be prevented with -mno-fp-ret-in-387
The disadvantage of soft-FP is that you wind up with lots of different
libc's - one for h/w FP, one for soft FP and maybe a few more for
different FP formats (eg FFP on M68K, or a `cut-a-few-corners-but-
give-almost-the-correct-answer-much-faster' IEEE, or single-precision
only IEEE). This is less of a problem in an embedded system, where
the FP requirements (if needed at all) are well defined. (The problem
is that using the wrong library generally doesn't show up until
run-time - when the results aren't what you expected).
Note that the GNU newlib defines `iprintf()' (and family) as an
integer-only printf() to avoid pulling in all the FP overhead when
it's not really needed.
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
