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

[Florian Klämpfl]

Am 09.03.2014 18:09, schrieb Vsevolod Alekseyev:
> I guess Free Pascal doesn't care for the same platforms that I do :) And
> that would be the mobile ones - iOS, Android, Windows Phone, bada. Windows
> Mobile is kind of comatose now, but still. Within this set, there's quite a
> zoo of ABIs; almost none of those have a *single* ARM ABI.

It is not only about ABI but also instruction set. You can also tell an
armhf compiler to use a softfloat abi but it will then look e.g. for a
wrong dyn. linker.

> Do I need to
> spell out that the mobile scene is kind of a Big Deal these days, and that
> the installed base of Android alone dwarfs that of Raspberry Pi by orders of
> magnitude?
> 
>> native compilation needs to "just work"
> 
> In case of said mobile platforms, making FPC work for those (espec.
> WinPhone) was a fun challenge that will look great on my resume, but
> definitely not something that "just worked". :)

Nobody said that it is supposed to work ;)

> 
>> You can't really mix code where the c calling convention is different.
> 
> I don't think so. Since the FP ABI of a unit is known at compile time, the
> compiler can be smart about it and generate argument translation thunks when
> necessary. The key concept is the notion of "effective calling convention" -
> that's the combination of the declared calling convention and the module's
> FP ABI. For every function call that crosses the FP ABI boundary, the
> compiler could generate a thunk and call that instead of the original
> function.

A properly generated object file encodes the abi so normally the linker
complains when you try to link object files with different abis.