crosstool-0.40 preview

[Martin Guy]

> Without the tweak crosstool's arm toolchain generates
>
> - vfp for -msoft-float
> - fpa without flags
> - hardfloat for -mhard-float

You may be confusing matters here. With ARM FP there are three levers to set:
- FP representation (FPA representation or IEEE-754)
- FP code generation (FP instructions for FPA or VFP or iwmmxt/xscale
or MaverickCrunch, all of which have different instruction sets)
- FP implementation mechanism (a real FPU executing real instructions,
soft float library calls or kernel or userland emulation by trapping
illegal instruction)

oh, and probably these days a fourth:
- ABI used for floating point calls in userland
but don't mention that yet.

To get library compatability for uboot, kernel and userland  I think you need to
decide whether it is a representation, implementation or code generation issue.
Does uboot need to initialise the VFP processor or do lots of FP or something?
Or is it just a library-compatability problem so that you can link it,
as it seems?

gcc's default FP representation follows the processor/FPU combination that
you select, or defaults to FPA if none is given or IEEE if
-msoft-float is given.
That is why ARM people often say "soft float" when they mean IEEE754,
since that was the only context it occurred in (or nowadays they say "VFP").

The reason is that historically the first physical FPU and the first set of
soft-float code that became available historically used FPA and IEEE
respectively, but changing the default selection mechanism would probably
break things that rely on it. Like Debian frinstance.

    M

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.org