Hello List, All This is the first time I'm writing to the list so if I provide incomplete information please bare with me and let me know what to improve, as I'm keen on solving the issue I am going to present. I am building a debian based installation of linux on a MIPS 32bit little endian box that has no FPU. Currently the state of affairs is that floating point operations take ages to execute due to the fact the floating point support is implemented thorough hardware emulation in the kernel, and incurs an exception handling performance penalty. so to solve this I'd like to be able to make GCC not provide it's current default floating point support through assembly and an exception, but to call a custom provided function instead, providing the same functionality like the commonly used math operators. This will enable me to have software floating point support without having to rebuild software or to risk externally provided binaries from partners to not work or crash due to different calling conventions. So to make myself more clear, we want to change the assembely generation that GCC does for floating point in a way that instead of , for example, for the '/' operator it will produce a set of assembly commands that will push the values into registers, attempt the DIV operation, fall into an exception (since there is no FPU on the system) the kernel will catch this exception and do its soft fpu magic etc, instead we want GCC to put assembly function calls to functions and routines we will provide to it to process floating point operations , and thus circumvent the exception handling mechanism and have better performance, while still preserving binary compatibility / calling convention to externally provided binarues that we have no source code for and thus can't rebuild. Those binaries will still use the exception handling mechanism for fp operations. There's gotta be a table or an index somewhere where we can change this to our needs, does anyone have an idea regarding this? has anyone tried this before? A billion thanks in advance, Sivan
