[fpc-devel] ARM: problem with uses VFP instructions

[Dariusz Mazur]

Dariusz Mazur pisze:
> Jonas Maebe pisze:
>>
>> On 02 Dec 2009, at 15:17, Dariusz Mazur wrote:
>>
>>>   *
>>>
>>>     __VFP_FP__ means that the floating point format in use is that of
>>>     the ARM VFP unit, which is native-endian IEEE-754.
>>>
>>>   *
>>>
>>>     __MAVERICK__ means that the floating point format is that of the
>>>     irrus Logic MaverickCrunch
>>>     <http://wiki.debian.org/MaverickCrunch>, which is also IEEE-754
>>>     and is always little-endian.
>>>
>>>   *
>>>
>>>     __SOFTFP__ means that instead of floating point instructions,
>>>     library calls are being generated for floating point math
>>>     operations so that the code will run on a processor without an FPU.
>>>
>>> __VFP_FP__ and __MAVERICK__ are mutually exclusive. If neither is 
>>> set, that means the floating point format in use is the old 
>>> mixed-endian 45670123 format of the FPA unit.
>>>
>>> Note that __VFP_FP__ does /not/ mean that VFP code generation has 
>>> been selected. It only speaks of the floating point data format in 
>>> use and is normally set when softfloat has been selected. The 
>>> correct test for VFP code generation, for example around asm 
>>> fragments containing VFP instructions, is
>>>
>>>
>>> My question is: which variant use FPC
>>
>> By default, on ARM/EABI FPC uses native-endian IEEE-754, but uses 
>> library calls (to internal code in the RTL) to emulate the floating 
>> point operations. So it's a combination of __VFP_FP__ and __SOFTFP__.
>>
> I found that crti.o linking form toolchain is without VFP, i try to 
> recompile this
>
>

At last I made it,
I have new uclibc library compiled with VFP

for others
I use OpenWRT, to recompile
make menuconfig
add  in advanced configuration/toolchain/target optimization
-mfpu=vfp

after make i receive in toolchain path
readelf -a crti.o show flags: soft float and VFP












-- 
  Darek