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: > >> 2560000 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
