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

[peter green]

> 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. 
I'm pretty sure it is getting set because I use it in generating the 
assembler command line and i'm using an assembler wrapper that tells me 
what the assembler command line is.

> 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,
I'll try but I'm having great trouble understanding how the code 
generator works.

I suspect the next thing I actually need to do is  come up with a 
reduced testcase. The assembler output of system.pp is MASSIVE.

>  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
>   
Ok i'll try and remember that.
> * is hard float really only supported on ARMv7-A? There are several ARMv6 platforms that also support VFP.
>   
I belive it is in principle possible to use the hard float ABI with 
ARMv6. Not sure if any distro is doing so though. If there are it may 
make sense to make ARMv6 the default for an armhf compiler.
> * 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. 
Currently the only FPC_ARMHF defines are selecting different defaults. 
You should still be able to select either ABI manually with either 
compiler binary if you wish.
> You can always select the appropriate default ABI via the global configuration file.
>   
You can but IMO it's neater to have a compiler built to use appropriate 
defaults for the system it's running on than to mess with generating and 
updating architecture specific configuration files.

> * "eabivfp" as a name for the ABI is confusing. The existing VFP support also uses the eabi. 
But it doesn't use the vfp variant of eabi.....
> Something like eabihardfp would be better.
>   
mmm, I mused a bit over that name. It is at least in principle possible 
to have EABI variants for FPUs other than vfp. I don't think any 
currently exist though and if they do I guess one could always select on 
the FPU type. So maybe eabihf or eabihardfloat is indeed a better choice.