Re: [fpc-devel] ARMHF a separate CPU? Why?
Am 10.03.2014 02:36, schrieb Vsevolod Alekseyev: It looks to me like development by drive-by patch has been going for quite a while. I smell burnout... We are waiting for a patch set for an easy to use WP8 compiler :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
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. 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. :)
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.
As for the thunks, there's nothing magical about those. I wrote some of them
manually during my porting efforts. Here's one for a hard-FP function that
takes two doubles and returns a double:
MyFunc_thunk:
fmdrr d0, r0, r1
fmdrr d1, r2, r3
stmfd sp!, {lr}
blx MyFunc
ldmfd sp!, {lr}
fmrrd r0, r1, d0
bx lr
Here's another, from another project, for a hard-FP function that takes a
single double argument and returns an int, written to be PIC compliant, and
switching mode into Thumb:
MyFunc_thunk:
fmdrr d0, r0, r1
MyFunc_ref:
add r12, pc, #(MyFunc - MyFunc_ref - 7)
bx r12
Naturally, the effective calling convention needs to be applied to function
pointer datatypes, too. When a pointer to a soft-FP function is being
assigned to a variable of a datatype that was declared in a hard-FP module,
it's a thunk address that needs to be assigned instead. Same goes for
scenarios with implicit function pointers - interface implementation,
virtual function overriding, etc.
This will break spectacularly in sketchy cases that involve casting function
pointers to void pointer or, worse yet, ints, and then back. But those are
sketchy anyway. Even GCC doesn't handle them right in all cases.
-Original Message-
From: fpc-devel-boun...@lists.freepascal.org
[mailto:fpc-devel-boun...@lists.freepascal.org] On Behalf Of peter green
Sent: Saturday, March 08, 2014 11:13 PM
To: FPC developers' list
Subject: Re: [fpc-devel] ARMHF a separate CPU? Why?
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
Re: [fpc-devel] ARMHF a separate CPU? Why?
On 09 Mar 2014, at 18:09, Vsevolod Alekseyev wrote: 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. At least iOS has a single ARM ABI (except on ARM64, but that's a completely different architecture in spite of the ARM name). And generating thunks all over the place would definitely not be my definition of properly supporting anything; especially on mobile platforms, where efficiency is key. 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? You're barking up the wrong tree. Platforms are only as well supported as there are people who care about it and invest time in it. Saying that someone else should invest time in a platform because of X (where X is it has a large market share, it will be the next big thing, it will gain you a lot of new users, etc), is useless. In fact, it's usually niche platforms that get the most attention because there you often have people that really care about the platform. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
It's your compiler; take it in any direction you want. I'm just surprised that Peter Green's first thought when I say ARM is Raspberry. As for those FP-ABI thunks of mine, I've only learned that ARMHF is an option, like, a few days ago, from this very maillist. There are all kinds of goodies in the FPC trunk, but it takes a nontrivial effort to find out about them. -Original Message- From: fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-boun...@lists.freepascal.org] On Behalf Of Jonas Maebe Sent: Sunday, March 09, 2014 1:24 PM To: FPC developers' list Subject: Re: [fpc-devel] ARMHF a separate CPU? Why? On 09 Mar 2014, at 18:09, Vsevolod Alekseyev wrote: 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. At least iOS has a single ARM ABI (except on ARM64, but that's a completely different architecture in spite of the ARM name). And generating thunks all over the place would definitely not be my definition of properly supporting anything; especially on mobile platforms, where efficiency is key. 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? You're barking up the wrong tree. Platforms are only as well supported as there are people who care about it and invest time in it. Saying that someone else should invest time in a platform because of X (where X is it has a large market share, it will be the next big thing, it will gain you a lot of new users, etc), is useless. In fact, it's usually niche platforms that get the most attention because there you often have people that really care about the platform. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
In our previous episode, Vsevolod Alekseyev said: It's your compiler; take it in any direction you want. I'm just surprised that Peter Green's first thought when I say ARM is Raspberry. Not that surprising if you know him: http://www.raspbian.org/RaspbianTeam ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
A properly generated object file encodes the abi so normally the linker complains when you try to link object files with different abis. Not if generated from assembly :) Which is exactly how the Pascal code works in my WinPhone and bada ports. Oh, and when I say fun challenge I mean dirty unsupported hack that will probably break from looking at it too hard. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
On 09 Mar 2014, at 18:47, Vsevolod Alekseyev wrote: It's your compiler; take it in any direction you want. My point was exactly that it's /not/ me that decides the direction in which the compiler goes, and even less as to which platforms get more attention than others. If someone cares a lot about MSDOS and starts implementing a 8086 code generator and MSDOS support, than that gets added (which, incidentally, has been happening over the past year). It's the same with ARM platform support. I'm just surprised that Peter Green's first thought when I say ARM is Raspberry. It's probably because it's the platform that he cares about most. As for those FP-ABI thunks of mine, I've only learned that ARMHF is an option, like, a few days ago, from this very maillist. There are all kinds of goodies in the FPC trunk, but it takes a nontrivial effort to find out about them. You're absolutely right that this needs to be fleshed out better. Most of the ARM platform support (not code generator, that's separate), except for iOS, has however been added via drive-by patches or just a bit of quick hacking until it worked for a single person, rather than by people want to commit themselves as full time maintainers of FPC for those platforms (including building/packaging releases for all relevant distributions/platforms, following up on all related bug reports etc). Combined with the mishmash that is ARM ABIs and sub-platforms, the situation is less than satisfactory at this time. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
On 09.03.2014 18:09, Vsevolod Alekseyev wrote: 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. :) Considering that you did something not supported by us yet (WinPhone) you shouldn't be surprised :P Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
Vsevolod Alekseyev wrote: It's your compiler; take it in any direction you want. I'm just surprised that Peter Green's first thought when I say ARM is Raspberry. When I did the armhf port I was targetting it at arm linux hence I fitted it into the exiting frameworks used for arm linux. I have no idea on the status of other arm ports because they aren't platforms I personally care about. I made my post to correct various misconceptions about the port that were flying arround on the list, for example the fact that some people thought it was a new CPU target. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
Well, the iOS support in FPC could use some love, too. Out of three iOS target architectures that Xcode 5.x supports, FPC only generates code for one. And the installation process isn't exactly straightforward, either. The Xcode templates for Pascal aren't even a part of FPC proper. It looks to me like development by drive-by patch has been going for quite a while. I smell burnout... You're absolutely right that this needs to be fleshed out better. Most of the ARM platform support (not code generator, that's separate), except for iOS, has however been added via drive-by patches or just a bit of quick hacking until it worked for a single person, rather than by people want to commit themselves as full time maintainers of FPC for those platforms (including building/packaging releases for all relevant distributions/platforms, following up on all related bug reports etc). Combined with the mishmash that is ARM ABIs and sub-platforms, the situation is less than satisfactory at this time. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] ARMHF a separate CPU? Why?
Does Free Pascal really treat ARMHF as a separate CPU target, 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. Yet the latter features are mere options within the ARM target. Was this done so that you can have several instances of ARM RTL side by side and switch between them seamlessly? But you can anyway. I, for example, am building my project for the two official flavors of Android (armeabi and armeabi-v7a). The RTL for the former was built with all default options and resides under units\arm-android. The RTL for the latter was built with CROSSOPT=-CpARMV7A -CfVFPV3_D16 and resides under units\armv7-android. In order to build the project for V7A, I provide the following extra options to FPC: -n -Fu$(FPCUNITS)/armv7-android/* And it works as expected. Could've accomplished the same with some editing of fpc.cfg. What I'm saying here, there are too many flavors of ARM out there that are actually in use by devices and platforms; introducing an extra CPU type does a poor job of providing support for all of them anyway. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
Am 08.03.2014 16:40, schrieb Vsevolod Alekseyev: Was this done so that you can have several instances of ARM RTL side by side and switch between them seamlessly? Debian made armhf a separate architecture so we decided to make it a separate compiler. units\armv7-android. In order to build the project for V7A, I provide the following extra options to FPC: -n -Fu$(FPCUNITS)/armv7-android/* This might work in simple setups but break in more complex like cross setups etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
Thanks, that explains. Mine *is* a cross setup. I'm buiding for Android (and more) on Windows/Intel. . -Original Message- From: fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-boun...@lists.freepascal.org] On Behalf Of Florian Klampfl Sent: Saturday, March 08, 2014 11:20 AM To: FPC developers' list Subject: Re: [fpc-devel] ARMHF a separate CPU? Why? Am 08.03.2014 16:40, schrieb Vsevolod Alekseyev: Was this done so that you can have several instances of ARM RTL side by side and switch between them seamlessly? Debian made armhf a separate architecture so we decided to make it a separate compiler. units\armv7-android. In order to build the project for V7A, I provide the following extra options to FPC: -n -Fu$(FPCUNITS)/armv7-android/* This might work in simple setups but break in more complex like cross setups etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
Am 09.03.2014 05:12, schrieb peter green: Cross compiling is a different case, those doing crossbuilds generally expect to have to do some manual configuration to get a working environment. We also aim at flawless cross compilation but this works so far only if the target is windows. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
