[fpc-devel] freepascal on armhf again
plugwash at p10link.net
Sun Mar 4 19:32:57 CET 2012
> Maybe this will help you:
> Thus additionially defining -Cparmv6 might allow the build to be
I did find the issue though, it seems freepascal wasn't passing a fpu
type parameter to the assembler for any case except softfloat.
I fixed that but in the process discovered that freepascals vfpv3
support is the "d32" version of vfpv3 (yes arm floating point is a mess)
so I decided to try and add a vfpv3_d16 "fpu type". However when I did
so the compiler started outputting a rfs and wfs instruction when
compling the system unit which the assembler didn't like. I eventually
tracked that down to inline assembler in the RTL. Maybe we should add a
FPU_VFP define that is defined for all VFP variants so we don't have to
mess with the ifdefs in the RTL every time we want to add a variant of
VFP (afaict there are a lot of VFP variants).
In the process of working on that I discovered another problem,
according to a comment in the source freepascal's register allocation
does not currently understand the concept of two single precision
registers that overlap with one double precision register, this will
make correctly implementing the "eabi vfp hardfloat" calling convention
difficult but i'm going to get passing doubles working before I worry
about the complications involved in passing singles (and even worse
passing a mixture of singles and doubles).
I've attatched the diff of what i've done so far.
P.S. (mostly as a note to self) i'm currently using the following
commands to build
make compiler_cycle 'OPT=-dFPC_ARMEL' 2>&1 | tee ../buildlog
cp compiler/ppcarm /
make compiler_cycle PP=/ppcarm 'OPT=-dFPC_ARMEL -CfVFPV3_D16 -CpARMV7'
2>&1 | tee ../buildlog
Next step will be to modify the code in cpupara.pas to actually start
passing values in vfp registers.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 16280 bytes
Desc: not available
More information about the fpc-devel