[Ack, I do understand there's a performance hit when gong via libgcc, but I was hoping this could be a good compromise between not using hardware FPU at all and generating traps on systems without FPU.]
Concerning libm as a candidate for opts: libm is in libc which is definitely a candidate for an optimized version; for example with have an i686 version for the i386 arch which provides an alternate libm: http://packages.ubuntu.com/jaunty/i386/libc6-i686/filelist Thanks for the details on supported traps; allow me to recap to make sure I understand this correctly The mainline kernel (we're primarily looking at 2.6.28 in jaunty) supports some traps out of the box, but only: - to handle VFP state saving and restoring across context switches (I guess this is to avoid saving/restoring the FPU regs when the switched to context doesn't need that) - to emulate some corner cases not supported by all hardware FPUs - on math errors and we don't need to patch anything to get the above when we're using VFP instructions in programs. Perhaps we need to turn on some kernel CONFIG_s in our armel flavours though? Otherwise, the mainline kernel can't emulate the base set of VFP instructions which ARMv5 and v6 cores with a FPU support on systems which lack a FPU (such as the Xscale example); we could perhaps patch this in, but it's not wanted in the mainline because it's too slow. I take it that the response from Linux developers is that we're supposed to not use VFP instructions in userspace on systems without a FPU? I didn't find any flags in the gcc man page about VFPv2 or v3: I guess one can only tell gcc to generate instructions for the full VFP set or not at all. -- armel gcc default optimisations https://bugs.launchpad.net/bugs/303232 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
