This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 1 Feb 2004 at 22:36, Dan Kegel wrote: > arm fixes: > * patches/gcc-3.3.2/gcc-3.3.2-arm-softfloat.patch, arm-softfloat.dat, > and demo-arm-softfloat.sh added for people who want to switch to the > soft float ABI for higher floating point performance > This is from Robert Schwebel's cvs version of the ptxdist patch repository, > so he hasn't really released it yet, but it does build. After all the soft-float discussion and Richard Earnshaw from ARM telling that the Linux/ARM ABI approves only the hard-float, this "soft float ABI" sounds somehow being 'unstandard'... What on eath is wrong with the Linux kernel and with the FPU-emu for ARM in it? With the PPC and MIPS FPU-emus ? Is the x86's '*87' emu the only working FPU-emu in Linux? All the people working with embedded 16-bit targets probably know that the FPU-routines coming with GCC are terribly slow and their main purpose isn't speed but maybe conformance with the IEEE float standards. And that there are alternative much quicker routines like the 'ieeefloat.c' granted to FSF by the Swedish Swox AB or something. Some years ago this replacement was tested with the H8/300 target by me and found to produce about 2 times quicker float operations than the standard 'fp-bit.c' coming with the GCC sources. The optimal approach could of course be having the soft-float package in manually optimized assembly for each target CPU architecture. For instance in the told H8/300 case the commercial IAR compiler still produced 5 times quicker float calculations after the 'fp-bit.c' -> 'ieeefloat.c' change So that there is something (the FPU-emu) still slower than the GCC's 'fp-bit.c', is really wacky and unexpected... Any Linux people working with the ARM, PPC and MIPS CPUs and trying to get their FPU-emulations quicker ? This would be the best and the recommended approach, not inventing dirty unstandard hacks using the 'fp-bit.c' and '-msoft-float'. I cannot imagine the exceptions, traps etc. handling with the unexisting fpu-opcodes being so slow that this would be the reason to use direct calls to the (very slow) soft-float routines in libgcc. Maybe the FPU-emu routines themselves are too slow, but as is the case with the 'fp-bit.c', there can be much quicker implementations. What could be wacky, is that in two FSF-projects, GCC and GNU/Linux, the soft-float implementations would be different. Or is there any reason why the 'fp-bit.c' algorithms couldn't serve in the FPU-emu? Aren't the 'fp-bit.c' routines re-entrant (several processes using the same code at the same time would require that) or what? Cheers, Kai ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |