I am trying to understand how to work with the various floating point options available for FPC when running on ARM under Linux. I'm not to familiar with all this so please bear with me.

Specifically I have a system comprising an TI OMAP3530: ARM CORTEX A8 running Linaro. /proc/cpuinfo reports it as:

Processor : ARMv7 Processor rev 2 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3

I notice that when compiling for ARM GCC, by default, generates floating point instructions like "fmuls s3, s11, s3" however if the -msoft-float option is given then GCC generates calls to software floating point routines like "bl __aeabi_fmul".

The former is somewhat faster and of course what I would like to achieve under FPC.

So far I have managed to build, using the lazarus_first_time script, an FPC cross compiler for ARM running on my PC, version 2.5.1. Additionally I have built a native compiler on the ARM board from subversion sources. Compiled using the ppcarm created on the PC.

I built the native compiler with a command like:

$make clean all PP=/path/to/ppcarm PREFIX="/opt/fpc-svn" OPT="-dFPC_ARMEL -O- -dFPC_ABI_EABI"

The resulting compiler works on the target but it generates software floating point instructions like "bl float64_mul".

Here I get stuck. I cannot get FPC to generate floating point instructions.

Adding any floating point options to FPC when compiling my application, like -CfVFPV3, results in errors like:

PPU Loading /opt/fpc-svn/lib/fpc/2.5.1/units/arm-linux/rtl/system.ppu Trying to use a unit which was compiled with a different FPU mode

Trying to rebuild my native compiler on the target with -CfVFPV3 in the options fails with errors about "selected CPU does not support ARM mode:....." for all of the floating point instructions generated.

Is there anyway to get FPC to generate floating point code similar to that produced by GCC by default?

Is there a way to rebuild just the units such that they are in the same FPU mode?

Thanks for any help.

Those errors come from the assembler, not from FPC. You probably have to add -Cparmv6. See also http://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_VFPv2_and_VFPv3

Jonas

I think that it should work if you do it like:

make clean all PP=/path/to/ppcarm PREFIX="/opt/fpc-svn" OPT="-dFPC_ARMEL -O- -dFPC_ABI_EABI -CfVFPv3"

It could be that there are simply some options missing to gas. It should generate assembler files. You could try to call the assembler manually and see what options it takes. I think some versions need "-march=armv7+vfp3" or something like that

Thankyou for the tips re: floating point on the ARM. I have had some success.

Firstly uusing -CfVFPv3 in the options like so:

$ make all PP=/home/linaro/ppcarm_2.5.1 PREFIX="/opt/fpc-svn"
OPT="-dFPC_ARMEL -O- -dFPC_ABI_EABI -CfVFPv3"

did not do the trick. Neither did adding -Cparmv6 to the options. With these in place the compilation works but the assembly fails with errors like:

Error: selected processor does not support ARM mode `fmuld d0,d0,d1'

I do not have gas on the ARM board but as. OK I found I could assemble system.s manually by adding the options -mcpu=armv6 -mfpu=vfpv3 to the as command.

So create a script called "as" that simpley calls the original as and adds those options. BINGO I can now build a compiler that generates hardware floating point instructions.

With that I can build our app. This was rather dramatic. An almost doubling of the execution speed!! Which is rather critical for us as we were pushing the limits of this board.

So it seems fpc does not pass the correct options to as. Is there anyway I can make it do so? My approach is obviously something of a hack.

Thank you all.

michael wrote

So it seems fpc does not pass the correct options to as. Is there anyway I can make it do so? My approach is obviously something of a hack.

Not as it is currently. I don't know why fpc doesn't pass the cpu argument to gas. I guess it's because the arguments are different over different binutils versions?

OK, I will have to live with my as fpu hack for the time being.

A couple of question:

1) I have built an ARM cross compiler on my PC with lazarus_first_time. How can I get that script to build a cross compiler with the required hardware floating point support?

2) I understand that ARM is not a tier one architecture for FPC and that the available ARM binaries from frrepascal.org are getting quite old now.

Is this a situation that is likely to change soon? With the explosive growth of the ARM processor in mobile and embedded devices it would seem time that it was a tier one architecture.

Tier one or not depends on someone who is willing to spend time on maintaining, packaging and supporting it. With ARM this is particularly time intensive because there are so many different ARM platforms (little/big endian, ARMv4/v5/v6/v7, OABI vs EABI, softfp vs AFP vs VFPv2/VFPv3, embedded/direct hardware vs Linux vs Android's Linux variant). If you support one, people immediately expect that you support all of them. Furthermore, unfortunately a lot of people who start working with FPC on ARM actually have very little experience with ARM and therefore often don't even know what variant they have or need, or what the consequences are.

The main reason no new ARM releases have been packaged is because packaging one mainly results in a lot of questions from people who downloaded/installed it and then notice that the code simply crashes (because it turns out they have an incompatible platform compared to what the package was built for).

I think it's really a "full time spare time" job to officially support ARM, even if you pick only a subset of all possible platforms.

Jonas

PS: for iOS, it is in fact sort of officially supported, although there the problem is that Apple's tools and SDK evolve very quickly so it is hard to keep up.

Hi,

... and has the hardware.

Nevertheless, there will be a 2.4.4 release for ARM/linux (barring any last-minute showstoppers) ARMv5/EABI/softfloat, an rc1 is already on the ftp. There will be an ARM/iOS crosscompiler release too.

There are daily tests run for ARM/linux for both stable and trunk (see http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?os=15&cpu=6&version=0&date=). At least for 2.5.1 the number of failures has been in the "okay"-range for some time now.

I think it's really a "full time spare time" job to officially support ARM, even if you pick only a subset of all possible platforms.

Ack.

Thomas

Anyone working on any free software project can get an account on the GCC compile farm: http://gcc.gnu.org/wiki/CompileFarm

They "only" have ARMv5 and ARMv7 machines, but it's better than nothing.

Nevertheless, there will be a 2.4.4 release for ARM/linux (barring any last-minute showstoppers) ARMv5/EABI/softfloat, an rc1 is already on the ftp. There will be an ARM/iOS crosscompiler release too.

There won't be an iOS 2.4.4 release, because it would barely work with current iOS SDK releases:
a) as of Xcode 3.2.0, simulator builds require the iphonesim target that only exists in 2.5.x
b) as of Xcode 3.2.6 and Xcode 4, all object files (including those generated by the resource compiler) must having matching ARM architecture identifiers of the linker will refuse to link them, and there does not appear to be a way to override this anymore (this hasn't even been fixed in fpc trunk yet)

Jonas

OK. I understand the magnitude of the problem. I seem to have spent the best part of a week wrapping my head around all the different ARM variants and their different floating point capabilities. Not to mention ABIs etc etc. Before we even get onto all the different operating systems and such.

Turns out that there is no Linux distribution that supports the fastest "hard" floating point abi. Closest I have come is that Linaro are working on such a thing and it involves rebuilding the distribution from the ground up fo that ABI.

So, yes, I am guilty of jumping into Pascal/ARM/floating point, inoccent of the complications ahead.

Luckily, thanks to your tips, I have a compiler that works well enough on the ARM platform with the speed boost of VFPV3. The cross compiler would be convenient but can wait. I will no doubt fight with it again as and when I have free moments.

Thank you again for your help.

What has to be done to get trunk working with XCode 4 ?

helmut

To clarify: that only affects iOS. Plain Mac OS X compilation works fine with Xcode 4 (better than with Xcode 3 in fact, since the linker bug ://www.freepascal.org/down/i386/macosx-ftp.freepascal.org.var under "Mac OS X 10.6 (Snow Leopard) compatibility" has been fixed).

As for iOS, see the attached messages.

Jonas

Thank you very much for your help.
It was not trivial (at least for me) to do the build, so i want to give feedback how it worked for me.

1) I tried to install the last fpc ios 2.5.1 snapshot (wiki iPhoneSnapshot-2.5.1-r14397)

-> failure due to only XCode4 and iOS SDK 4.3 available -> and SDK not found by fpc after install script

2) Patched: "finish_fpc_iphone_install.command"

[…]
# Obtain the installation directory of the SDK.
[…]
+ elif [ -f "/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk/usr/include/arm/_structs.h" ]; then
+ IPHONEINSTALLDIR=/Developer
+ IPHONESDKDIR=iPhoneOS4.3.sdk
[…]

Resulting in :

ld: warning: -ios_version_min not specificed, assuming 4.3

ld: object file /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk//usr/lib/crt1.o was built for different arm sub-type (6) than link command line (0) for architecture arm An error occurred while linking
pp.pas(224,1) Error: Error while linking
pp.pas(224,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
make[3]: *** [ppcarm] Error 1
make[2]: *** [cycle] Error 2
make[1]: *** [compiler_cycle] Error 2
make: *** [build-stamp.arm-darwin] Error 2
An error occurred during building everything for ARM When asking for help with this error, please provide the entire contents of this window (you can copy/paste it)

You can restart this script by double-clicking it in the Finder at /Developer/FreePascalCompiler/iPhoneSnapshot-2.5.1-r14397/InstallScript/finish_fpc_iphone_install.command

3) Now I copied the translated "sig_cpu.inc" to my svn trunk checkout "rtl/darwin/arm/" dir
4) Applied the cpu subarch type patch from jonas
5) regenerated the fcl-web makefile with the original version (cp Makefile.org Makefile.fpc then fpcmake -Tall)
Due to Error:
HHMacBookPro:trunk helly$ sudo make FPC=/usr/local/lib/fpc/2.4.2/ppc386 CPU_TARGET=arm CROSSOPT="-FD${IPHONEPLATFORMBASEDIR}/usr/bin -XR${IPHONEPLATFORMBASEDIR}/SDKs/iPhoneOS4.3.sdk/ -ap -Cfvfpv2" all […]
make -C fcl-web clean
./fpmake clean --localunitdir=../.. --globalunitdir=.. --os=darwin --cpu=arm -o -Parm -o -Ur -o -Xs -o -O2 -o -n -o -Fu/Users/helly/pascal/bzr_fpc/trunk/rtl/units/arm-darwin -o -Fu/Users/helly/pascal/bzr_fpc/trunk/packages/hash/units/arm-darwin -o -Fu/Users/helly/pascal/bzr_fpc/trunk/packages/paszlib/units/arm-darwin -o -Fu/Users/helly/pascal/bzr_fpc/trunk/packages/fcl-process/units/arm-darwin -o -Fu/Users/helly/pascal/bzr_fpc/trunk/packages/fpmkunit/units/arm-darwin -o -FE. -o -FUunits/arm-darwin -o -darm -o -dRELEASE -o -FD/Developer/Platforms/iPhoneOS.platform/Developer//usr/bin -o -XR/Developer/Platforms/iPhoneOS.platform/Developer//SDKs/iPhoneOS4.3.sdk/ -o -ap -o -Cfvfpv2 --compiler=/Users/helly/pascal/bzr_fpc/trunk/compiler/ppcrossarm make[3]: ./fpmake: Bad CPU type in executable
make[3]: *** [clean] Error 1
make[2]: *** [fcl-web_clean] Error 2
make[1]: *** [packages_clean] Error 2
make: *** [build-stamp.arm-darwin] Error 2
[…]

6) Then finally:
sudo make FPC=/usr/local/lib/fpc/2.4.2/ppc386 CPU_TARGET=arm CROSSOPT="-FD${IPHONEPLATFORMBASEDIR}/usr/bin -XR${IPHONEPLATFORMBASEDIR}/SDKs/iPhoneOS4.3.sdk/ -ap -Cfvfpv2" all sudo make FPC=`pwd`/compiler/ppcrossarm OPT="-ap" CPU_TARGET=arm CROSSOPT="-FD${IPHONEPLATFORMBASEDIR}/usr/bin -XR${IPHONEPLATFORMBASEDIR}/SDKs/iPhoneOS4.3.sdk/ -ap" install CROSSINSTALL=1 sudo ln -sf ../lib/fpc/2.5.1/ppcrossarm /usr/local/bin/ppcarm

Yielded:
HHMacBookPro:trunk helly$ ppcarm
Free Pascal Compiler version 2.5.1 [2011/04/14] for arm […]

I have not tested the compiler by now, but was happy to build it. As next step I want to try to port some of our opengl/physics code to the iPad2.

helmut