On Wed, 25 Feb 2004, Robert Schwebel wrote:

On Tue, Feb 24, 2004 at 05:53:39PM +0100, Marius Groeger wrote:

...

In practice, however, I have not seen this kind of optimising as of yet. Maybe on ARM there is no gain in performance. Unless there is a proper (read: for all ARM architectures, and working like we know it from powerpc-linux) -msoft-float patch for GCC 3, I'm inclined to just (carefully) drop -msoft-float from *boot.

How do you handle the ARM variants which have a hardware FPU then? I didn't work with a cpu which has one yet, but there are some out there.

Well, the unpatched gcc assumes a hardware FPU, doesn't it? It appears that the ARM community has relied on their kernel FPEMU for years, unlike the ppclinux folks. (Which still puzzles me, as the kernel FPEMU surely must be a performance eater, don't you agree?)

As far as uboot and this ML is concerned, the real problem is that with the -msoft-float being thrown, the ELF files get labelled "uses soft float", which is not mixable with libgcc, which is labelled "uses hard fp". Regardless, the integer routines uboot is referencing are not affected in the slightest bit, yet they carry the "uses hard fp" stigma. This results in the error message some people report. (Note that the accuracy of the statements in that error message depends on the binutils version.)

Nico's and your gcc patch don't change this, but bring trouble to the non-uboot userland software (most notably binary incompatibility and StrongARM breakage). What the patch does bring, though, is real a true soft float implementation for PXA systems.

We should probably discuss that on crossgcc as there are others like Benedikt Spranger, Marc Kleine-Budde and Dan Kegel, who may give better comments on this than me, I didn't have time to investigate the problem

Sigh... too many mailing lists. But you're probably right. To be honest, I'm not subscribed to that list yet.

Regards, Marius