Re: Soft Float is not being reported

[Dimitry Andric <dimitry at andric dot com>]

On 2004-06-24 at 21:52:59 Dave wrote:

> Multilib has caused nothing but problems for me...I have steered away from
> it as much as possible. For developers who build for many different targets
> I can see the usefulness of it. For developers who target one platform with
> one FP type, one CPU, etc...I just don't see the benfit of multilib...am I
> missing something?

The benefit would be that you can use one toolkit for all targets.
Note that "multilibbing" for big- and little endian should also be
possible, etc.  It would be really nice to have one huge "killer"
toolchain, that can be used for almost all ARM units out there.


> Why would one want VFP softfloat. I spent some time researching VFP the
> other day and I still don't understand why it would/should be used in any
> case.

VFP uses native endianness for storing floats, and I simply presume
this is more efficient.  Nicholas Pitre even calls the FPA format a
"historical mistake" here:

http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2003-December/018687.html

and here is also a somewhat more detailed explanation:

http://lists.debian.org/debian-arm/2003/10/msg00030.html

OTOH, software floating point is always quite slow, so the difference
between softfpa and softvfp should not be too great.  I haven't
actually benchmarked it... not enough time, I'm afraid. :)


> So basically if I get gcc stage 1 to output softfloat by default, then build
> glibc with CC="arm-linux-gcc -msoft-float" I *should* end up with a
> softfloat libgcc + softfloat glibc?

No, if you build gcc stage 1 with default softfloat output, you DON'T
need to pass the -msoft-float flag anymore to the glibc and gcc-final
stages.  In fact, you never have to use it anymore, since all object
files will have softfloat already.

Attachment: pgp00000.pgp
Description: PGP signature