Re: [OpenWrt-Devel] use of soft-float on bcm47xx
On 2009.06.28. 22:29:45 Mattia Aracne arac...@hotmail.com wrote: Sotware floating point emulation is now enabled by default for mips and mipsel and the kernel FPU emulator is disabled by default with changesets 16605 and 16606. -- Best regards, Florian Fainelli Email : flor...@openwrt.org http://openwrt.org Applying this patches broke ADM5120 target. Testing OSBRiDGE 5GXi/5XLi profile with revision 16606 makes the boot process hang at Please be patient, while OpenWrt loads Works with revision 16600. As noted, you have to recompile everything - make distclean. Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
Le Sunday 21 June 2009 01:04:05 Jonas Gorski, vous avez écrit : 2009/6/21 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 23:56:51 Jonas Gorski wrote: 2009/6/20 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 00:09:56 Jonas Gorski wrote: 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. No you completely got me wrong. I am talking about the performance gain in real life. userspace soft float certainly _is_ faster than kernel float. But _if_ userspace soft float is bigger in size than kernel float, it probably is not worth the space tradeoff, because floating point is hardly used on a router. I apology, I really did misunderstand you. Did somebody test this: * Image with kernel FP emu disabled and userspace softemu enabled. * Image with kernel FP emu enabled and userspace softemu disabled. Which one is smaller? Disabling the kernel fpu emu isn't intended in linux, so I had to hack the emulation away, mainly by removing any fpu references in arch/mips/kernel/ until it compiled. I don't know if it really works, I don't have a second device for testing. I used the brcm47xx/default profile for testing, making distclean before compiling. With kernel-fpuemu and no softfloat: 256 openwrt-brcm47xx-squashfs.trx Without fpuemu and with softfloat: 2625536 openwrt-brcm47xx-squashfs.trx So the image with soft-float instead of the in-kernel fpu emulation uses one block more. For me this would be an acceptable increase. So what about the following. We introduce another option in the kernel config to disable fpuemu. This way the user can select either useremu, kernelemu or no emu at all. This probably is a win-win situation then. Because if I do care about space, I can turn off _both_ emulators. And you, who do care about performance, can set the openwrt default to kernelemu-off useremu-on. This would probably the best option. We should then test which applications/libraries need floating point support and mark these with an appropriate dependency. Going with no float support might require additional tweaking, as busybox seems to use floating point. Here comes a quick'n'dirty compile tested only patch which allows disabling the in-kernel FPU emulator. Could you guys test it with the toolchain having software floating point enabled and confirm that floating point operations still work ? -- MIPS: allow disabling the kernel FPU emulator This patch allows turning off the in-kernel Algorithmics FPU emulator support, which allows one to save a couple of precious blocks on an embedded system. Without the MIPS_FPU_EMU option, the kernel size for AR7 is: size vmlinux textdata bss dec hex filename 5647163 90772 87904 5825839 58e52f vmlinux With it enabled, same configuration: textdata bss dec hex filename 5701403 90804 87904 5880111 59b92f vmlinux In order nt to change the default behavior, this option is default y. Siged-off-by: Florian Fainelli flor...@openwrt.org -- diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 65d3b19..a467ee5 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -811,6 +811,17 @@ config I8259 config MIPS_BONITO64 bool +config MIPS_FPU_EMU + bool + default y + help + This option allows building a kernel with or without the Algorithmics + FPU emulator enabled. Turning off this option results in a kernel which + does not catch floating operations exceptions. Make sure that your toolchain + is configured to enable software floating point emulation in that case. + + If unsure say Y here. + config MIPS_MSC bool diff --git a/arch/mips/math-emu/Makefile b/arch/mips/math-emu/Makefile index d547efd..7fdef24 100644 --- a/arch/mips/math-emu/Makefile +++ b/arch/mips/math-emu/Makefile @@ -2,12 +2,14 @@ # Makefile for the Linux/MIPS kernel FPU emulation. # -obj-y := cp1emu.o ieee754m.o ieee754d.o ieee754dp.o ieee754sp.o ieee754.o \ +obj-y := kernel_linkage.o dsemul.o cp1emu.o + +obj-$(CONFIG_MIPS_FPU_EMU) += ieee754m.o ieee754d.o
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
Hi, I have one further suggestion. I have HAVE a DUAL mips3 with 64 megabytes of ram RUNNING on an FPGA. However, mips3 has a VERY small instruction set. So far I haven't been able to get the kernel to run AT ALL. The reason is because some of the more elegant MIPS instructions are used by the kernel even when compiled in mips3 mode :(. So I suggest ONE additional flag. __ - Emulate unimplemented mips instructions When my or your mips3 ( with its mini instruction set ) encounters an instruction it doesn't know how to handle, it is handled in emulation software. I presume there are already such emulators out there (PLEASE, PLEASE tell me where!). Also, custom instructions can EASILY be added without modifying the FPGA code! __ - Emulate USER special instructions warm regards, wiz (pen name) On Sun, 21 Jun 2009, Jonas Gorski wrote: 2009/6/21 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 23:56:51 Jonas Gorski wrote: 2009/6/20 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 00:09:56 Jonas Gorski wrote: 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. No you completely got me wrong. I am talking about the performance gain in real life. userspace soft float certainly _is_ faster than kernel float. But _if_ userspace soft float is bigger in size than kernel float, it probably is not worth the space tradeoff, because floating point is hardly used on a router. I apology, I really did misunderstand you. Did somebody test this: * Image with kernel FP emu disabled and userspace softemu enabled. * Image with kernel FP emu enabled and userspace softemu disabled. Which one is smaller? Disabling the kernel fpu emu isn't intended in linux, so I had to hack the emulation away, mainly by removing any fpu references in arch/mips/kernel/ until it compiled. I don't know if it really works, I don't have a second device for testing. I used the brcm47xx/default profile for testing, making distclean before compiling. With kernel-fpuemu and no softfloat: 256 openwrt-brcm47xx-squashfs.trx Without fpuemu and with softfloat: 2625536 openwrt-brcm47xx-squashfs.trx So the image with soft-float instead of the in-kernel fpu emulation uses one block more. For me this would be an acceptable increase. So what about the following. We introduce another option in the kernel config to disable fpuemu. This way the user can select either useremu, kernelemu or no emu at all. This probably is a win-win situation then. Because if I do care about space, I can turn off _both_ emulators. And you, who do care about performance, can set the openwrt default to kernelemu-off useremu-on. This would probably the best option. We should then test which applications/libraries need floating point support and mark these with an appropriate dependency. Going with no float support might require additional tweaking, as busybox seems to use floating point. Regards, Jonas Gorski ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
On Saturday 20 June 2009 00:09:56 Jonas Gorski wrote: 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. No you completely got me wrong. I am talking about the performance gain in real life. userspace soft float certainly _is_ faster than kernel float. But _if_ userspace soft float is bigger in size than kernel float, it probably is not worth the space tradeoff, because floating point is hardly used on a router. Did somebody test this: * Image with kernel FP emu disabled and userspace softemu enabled. * Image with kernel FP emu enabled and userspace softemu disabled. Which one is smaller? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
2009/6/20 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 00:09:56 Jonas Gorski wrote: 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. No you completely got me wrong. I am talking about the performance gain in real life. userspace soft float certainly _is_ faster than kernel float. But _if_ userspace soft float is bigger in size than kernel float, it probably is not worth the space tradeoff, because floating point is hardly used on a router. I apology, I really did misunderstand you. Did somebody test this: * Image with kernel FP emu disabled and userspace softemu enabled. * Image with kernel FP emu enabled and userspace softemu disabled. Which one is smaller? Disabling the kernel fpu emu isn't intended in linux, so I had to hack the emulation away, mainly by removing any fpu references in arch/mips/kernel/ until it compiled. I don't know if it really works, I don't have a second device for testing. I used the brcm47xx/default profile for testing, making distclean before compiling. With kernel-fpuemu and no softfloat: 256 openwrt-brcm47xx-squashfs.trx Without fpuemu and with softfloat: 2625536 openwrt-brcm47xx-squashfs.trx So the image with soft-float instead of the in-kernel fpu emulation uses one block more. For me this would be an acceptable increase. Removing the fpu support completely does have a positive side effect even for applications that don't use floats: There is no fpu context anymore, so the memory footprint of processes should be very slightly reduced, and context switches should be a little bit faster. While the first should be neglectable (if I read the sources correctly, 256 bytes), the latter might be even measurable. Regards, Jonas Gorski ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
On Saturday 20 June 2009 23:56:51 Jonas Gorski wrote: 2009/6/20 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 00:09:56 Jonas Gorski wrote: 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. No you completely got me wrong. I am talking about the performance gain in real life. userspace soft float certainly _is_ faster than kernel float. But _if_ userspace soft float is bigger in size than kernel float, it probably is not worth the space tradeoff, because floating point is hardly used on a router. I apology, I really did misunderstand you. Did somebody test this: * Image with kernel FP emu disabled and userspace softemu enabled. * Image with kernel FP emu enabled and userspace softemu disabled. Which one is smaller? Disabling the kernel fpu emu isn't intended in linux, so I had to hack the emulation away, mainly by removing any fpu references in arch/mips/kernel/ until it compiled. I don't know if it really works, I don't have a second device for testing. I used the brcm47xx/default profile for testing, making distclean before compiling. With kernel-fpuemu and no softfloat: 256 openwrt-brcm47xx-squashfs.trx Without fpuemu and with softfloat: 2625536 openwrt-brcm47xx-squashfs.trx So the image with soft-float instead of the in-kernel fpu emulation uses one block more. For me this would be an acceptable increase. So what about the following. We introduce another option in the kernel config to disable fpuemu. This way the user can select either useremu, kernelemu or no emu at all. This probably is a win-win situation then. Because if I do care about space, I can turn off _both_ emulators. And you, who do care about performance, can set the openwrt default to kernelemu-off useremu-on. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
2009/6/21 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 23:56:51 Jonas Gorski wrote: 2009/6/20 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 00:09:56 Jonas Gorski wrote: 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. No you completely got me wrong. I am talking about the performance gain in real life. userspace soft float certainly _is_ faster than kernel float. But _if_ userspace soft float is bigger in size than kernel float, it probably is not worth the space tradeoff, because floating point is hardly used on a router. I apology, I really did misunderstand you. Did somebody test this: * Image with kernel FP emu disabled and userspace softemu enabled. * Image with kernel FP emu enabled and userspace softemu disabled. Which one is smaller? Disabling the kernel fpu emu isn't intended in linux, so I had to hack the emulation away, mainly by removing any fpu references in arch/mips/kernel/ until it compiled. I don't know if it really works, I don't have a second device for testing. I used the brcm47xx/default profile for testing, making distclean before compiling. With kernel-fpuemu and no softfloat: 256 openwrt-brcm47xx-squashfs.trx Without fpuemu and with softfloat: 2625536 openwrt-brcm47xx-squashfs.trx So the image with soft-float instead of the in-kernel fpu emulation uses one block more. For me this would be an acceptable increase. So what about the following. We introduce another option in the kernel config to disable fpuemu. This way the user can select either useremu, kernelemu or no emu at all. This probably is a win-win situation then. Because if I do care about space, I can turn off _both_ emulators. And you, who do care about performance, can set the openwrt default to kernelemu-off useremu-on. This would probably the best option. We should then test which applications/libraries need floating point support and mark these with an appropriate dependency. Going with no float support might require additional tweaking, as busybox seems to use floating point. Regards, Jonas Gorski ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
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* textdata bss dec hex filename 22692442521744 232920 38dd8 /tmp/dropbear 23471943281744 240791 3ac97 /tmp/dropbear_sfloat 22078141921744 226717 3759d /tmp/dropbear_sfloat_sgcc 21995641521744 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. -- Best regards, Florian Fainelli Email : flor...@openwrt.org http://openwrt.org --- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
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* textdata bss dec hex filename 22692442521744 232920 38dd8 /tmp/dropbear 23471943281744 240791 3ac97 /tmp/dropbear_sfloat 22078141921744 226717 3759d /tmp/dropbear_sfloat_sgcc 21995641521744 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. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
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
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
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* textdata bss dec hex filename 22692442521744 232920 38dd8 /tmp/dropbear 23471943281744 240791 3ac97 /tmp/dropbear_sfloat 22078141921744 226717 3759d /tmp/dropbear_sfloat_sgcc 21995641521744 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? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
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. 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. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
