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
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] fpHttpClient heartbeat
From: Michael Van Canneyt >To: FPC developers' list >Sent: Saturday, March 8, 2014 2:42 PM >Subject: Re: [fpc-devel] fpHttpClient heartbeat > > >On Sat, 8 Mar 2014, Leonardo M. Ramé wrote: > >> Hi, does anyone know if fpHttpClient has something similar to the HeartBeat >> option of Synapse?, this feature is useful for >> implementing download progress bars, for example. > >It has an onprogress event, this is implemented in trunk. > >Michael. > > Sorry Michael, I cannot find that event, is in packages/fcl-web/src/base/fphttpclient.pp ?. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpHttpClient heartbeat
On Sat, 8 Mar 2014, Leonardo M. Ramé wrote: Hi, does anyone know if fpHttpClient has something similar to the HeartBeat option of Synapse?, this feature is useful for implementing download progress bars, for example. It has an onprogress event, this is implemented in trunk. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] fpHttpClient heartbeat
Hi, does anyone know if fpHttpClient has something similar to the HeartBeat option of Synapse?, this feature is useful for implementing download progress bars, for example. Leonardo M. Ramé http://leonardorame.blogspot.com___ 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?
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] 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
