2009/6/19 Michael Buesch <m...@bu3sch.de>: > On Friday 19 June 2009 18:20:53 Florian Fainelli wrote: >> Le Tuesday 09 June 2009 16:00:47 Michael Buesch, vous avez écrit : >> > On Monday 08 June 2009 21:35:05 matthieu castet wrote: >> > > Michael Buesch wrote: >> > > > On Sunday 07 June 2009 11:28:50 matthieu castet wrote: >> > > >> Hi, >> > > >> >> > > >> I wonder with openwrt for bcm47xx is not build with "-msoft-float". >> > > >> The cpu doesn't have fpu and the current floating code get emulated by >> > > >> the kernel emulator instead of using the gcc emulation support (that >> > > >> is cheaper because there is no kernel trap). >> > > > >> > > > Well, I guess on a typical bcm47xx setup there's hardly any application >> > > > that uses floating point math. >> > > >> > > note that dropbear seems to use some, but that not critical. >> > > >> > > > Does -msoft-float increase the binary/image size? If so, I'd >> > > > vote for _not_ adding -msoft-float. If it doesn't make a size >> > > > difference, we should probably add it. >> > > >> > > That shouldn't increase size of application that don't use float. >> > > I did a quick test with dropbear that contain very few float. >> > > Here are the results (sfloat means -msoft-float, sgcc mean >> > > -shared-libgcc) >> > > >> > > >> > > $size /tmp/dropbear* >> > > text data bss dec hex filename >> > > 226924 4252 1744 232920 38dd8 /tmp/dropbear >> > > 234719 4328 1744 240791 3ac97 /tmp/dropbear_sfloat >> > > 220781 4192 1744 226717 3759d /tmp/dropbear_sfloat_sgcc >> > > 219956 4152 1744 225852 3723c /tmp/dropbear_sgcc >> > > >> > > As you can see with a static libgcc the size of the softfloat binary >> > > increase (8k) because all float emulation code is duplicated in the >> > > binary. With a shared libgcc the softfloat binary is smaller, the >> > > increase size is less than 1k. >> > > >> > > I don't know the impact for whole binary. I should try to build a >> > > typical bcm47xx setup and see the impact. >> > >> > Ok. It still smells like we're trying to solve a problem that does not >> > exist. Is the performance of any app increased in real life? >> >> We can still allow soft-float to be used in the toolchain, and keep the >> in-kernel FPU emulator for compatibility, but then we will loose some space. > > Yeah well. That's my question. > Do we actually gain performance or do we only loose some space? > > If we do _not_ gain performance, it certainly is not a good idea to waste > space.
I would be very surprised if we wouldn't. Every kernel emulated floating point operation results in an exception and the appropriate handling (fpu emulation is ugly), while soft-float should stay completely in user space. Also, the mips fpu emulator itself suggests that. Quoting linux/arch/mips/math-emu/cp1emu.c: > * Note if you know that you won't have an fpu, then you'll get much > * better performance by compiling with -msoft-float! To get some numbers: Perhaps could somebody test with 'sample' from libmpcdec the difference in speed between in-kernel emulation and soft-float? https://dev.openwrt.org/ticket/4715 suggests that the library depends heavily on floating point when not using fixed point math. Regards, Jonas Gorski _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
