[fpc-devel] ARMHF a separate CPU? Why?

[peter green]

Vsevolod Alekseyev wrote:
> Does Free Pascal really treat ARMHF as a separate CPU target,
It didn't when I initally implemented it and from a quick look at the 
code it doesn't now. What it does do is a little hacky but it followed 
the pattern of what was already done and a cleaner soloution would have 
required more radical changes.
>  distinct from regular ARM? May I ask why such design? In the grand symphony of native code generation, the floating point calling convention sounds, to me, as a much smaller detail than, for example, ARM vs Thumb or PIC vs. non-PIC or floating point mode per se. 
Indeed from a code generation point of view those are probablly more 
significant. On the other hand from a compatibility point of view they 
are far less significant, you can mix code that uses arm with code that 
uses thumb, you can mix PIC code with non-PIC code and you can mix code 
that uses the FPU with code that does floating point in software with 
code that uses the fpu (though IIRC fpc blocks the latter on arm eabi 
for no good reason). You can't really mix code where the c calling 
convention is different.

You could in principle have a mode where the "cdecl" calling convention 
used to interact with c libraries put floating point values in integer 
registers while the calling conventions that are only used within pascal 
code used floating point registers but I haven't seen anyone propose 
implementing that.
> Yet the latter features are mere options within the ARM target.
>   
To understand the setup tets start from from a premise, namely that 
native compilation needs to "just work", if I build or download a native 
compiler for "platform x" I expect it to produce binaries that will work 
correctly (though they may not be optimal) on "platform x" without the 
need to be explicitly told how to do so at runtime.

Cross compiling is a different case, those doing crossbuilds generally 
expect to have to do some manual configuration to get a working environment.

A freepascal compiler built for a given OS will target that OS by 
default and each compiler only targets one CPU family. In most cases 
this just works, for most CPUs and operating systems that freepascal 
cared about the combination of OS and CPU locked down the ABI to one choice.

Unfortunately arm linux is an exception to this, there have been at 
least four different ABIs targetted by freepascal for arm linux and all 
of them have been used on systems that are more than capable of running 
native compilers. The way this is handled is a bit hacky, each ABI has a 
#define (FPC_OARM, FPC_ARMEL, FPC_ARMEB and FPC_ARMHF), when building 
the compiler this #define it will set the default ABI and a few other 
things (default linker script paths, default fpu). If none of the above 
defines are defined and a native compiler is being built then the 
setting will be inherited from the abi the compiler is being built for. 
If a crosscompiler is being built then the default is FPC_ARMEL.

I did not introduce this system, I merely expanded it to add armhf to 
the supported variants.

At least in my original armhf patches you could override all the 
settings that FPC_ARMHF implied (compared to the default FPC_ARMEL) 
manually with enough command line flags, I don't know if that is still 
the case, nor do I know if it is the case for other arm variants.

Florian later added code so that a compiler built for armhf and armv6 
would default to targetting armv6+vfpv2 rather than armv7-a+vfpv3_d16. 
This was done so that building and using the compiler on raspbian (and 
similar raspberry pi targetted distros) would "just work".