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]

Re: crosstool-0.27: added softfloat support for arm, lots of little fixes


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]