Date: Thu, 15 Jul 1999 12:47:36 +1000 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: imp@village.org Cc: freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? Message-ID: <99Jul15.122942est.40355@border.alcanet.com.au> In-Reply-To: <199907150214.UAA60347@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Jul15.122942est.40355>