[fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

[Jonas Maebe]

On 11 Mar 2012, at 13:00, peter green wrote:

> That in turn triggers a block of code that I added to options.pas which sets the default fpu to "fpu_vfpv3_d16" and errors out if the user manually specifies a FPU that is not a VFP variant.

Then I suggest you simply debug it like any other code: first set a breakpoint in options.pas where the fpu type should be set, and verify that it is in fact set. Then get the addresses of init_settings.fputype and current_settings.fputype, and set watchpoints on those to see whether they are still changed somewhere else. Also set a breakpoint in the code generator somewhere where it should decide whether to use AFP or VFP instructions, continue and see what goes wrong.

Some other comments about your patch:
* please do not write code like this:

if (target_info.abi <> abi_eabivfp) AND((p.proccalloption in [pocall_softfloat]) or
   (cs_fp_emulation in current_settings.moduleswitches) or
   (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then

Use this instead:

if (target_info.abi <> abi_eabivfp) and
   ((p.proccalloption in [pocall_softfloat]) or
    (cs_fp_emulation in current_settings.moduleswitches) or
    (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then

* is hard float really only supported on ARMv7-A? There are several ARMv6 platforms that also support VFP.
* I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. I think that there should be no problem to support both vfp-softfloat and vfp-hardfloat using the same binary, which should get rid of all the FPC_ARMHF defines. You can always select the appropriate default ABI via the global configuration file.
* "eabivfp" as a name for the ABI is confusing. The existing VFP support also uses the eabi. Something like eabihardfp would be better.


Jonas