Hi! >There are two floating point ABIs for arm-linux corresponding to the >calling conventions used for passing floating point parameters (memory >vs registers, I presume).
..and Floating point registers vs passing floats in integer registers ( split in two for doubles...grrrrr). A really good overview on Linux ARM ABI Q&A can be found at Debian, most of it should be valid in general for other Linuxes: http://wiki.debian.org/ArmHardFloatPort#Background_information >Here's where I start to get confused. Tell me if I've got this right. Let's see :-) >The gcc default is to use the soft float ABI, GCC will use the best default for the platform it was compiled for. E.g. on Debian "armhf" Linux port, it will use hard float by default. More on this later. >The gcc default is to use the soft float ABI, which results in the >generation of calls to implement emulations of floating point path. See the section "ld.so hwcaps" on the Debian page linked above. Even with soft ABI, there will be a benefit for devices actually having VFP hardware, it's not like soft-ABI implies software emulation. Still the overhead is considerable (a function call, some register shuffling, for each FP op) >If one specifies -mfloat-abi=softfp the compiler generates hardware >floating point instructions but uses the softfp call convention. Correct. >The hard float is chosen by -mfloat-abi=hard. For this a VFP is >required, but it is the most efficient mode. Correct. >FFTW 3.3.3, for some >reason, thinks this mode is incompatible with NEON SIMD code, though. I would consider this a bug, but I kind of doubt this is a problem. Here is a report of someone claiming to have used FFTW 3.3.3 with hardfloat ABI and NEON support enabled: https://bitbucket.org/jpommier/pffft (search the page for "--enable-neon" ) >So if I wanted to target the widest variety of devices. I'd make one >executable with the default (software) FP. I'd make one with softfp >including NEON code in FFTW. And I'd make one for hardfp without NEON >code in FFTW. The important point is that you are NOT free to decide which ABI (hard or soft(fp)) you want to use for a given target system. The target OS is either having libraries that are expecting getting values passed the "hard" or the "soft" way. If the target system is soft-ABI, you are free to choose soft or softfp code, tho. >I hope there's something in the BOINC headers or host >record that would tell me which one to send. The way to communicate the ABI of the host OS is the platform string. Presence of certain hardware and instruction set features for ARM CPUs are found in the CPU capabilities, but note that detailed support e.g. for detecting NEON or VFP were added only recently to BOINC. Some legacy BOINC installaions on ARM (e.g. BOINC from the official distribution repos) will not give you this information. >Android throws in another twist in that pre-ARMv7 devices can only use >software floating point. Android has two ABIs defined, pre ARMv7 and Armv7, but **both** are of the soft-floating point variant (!). In general, hardfloat code will not run correctly on Android devices. See the document docs/CPU-ARCH-ABIS.html of the Android NDK. Here's the crucial quote: ========= I.2. 'armeabi-v7a' [...] IMPORTANT NOTE: This ABI enforces that all double values are passed during function calls in 'core' register pairs, instead of dedicated FP ones. However, all internal computations can be performed with the FP registers and will be greatly sped up. This little constraint, while resulting in a slight decrease of performance, ensures binary compatibility with all existing 'armeabi' binaries. ======== which essentially says that even this ABI is a soft float ABI (!!). You can check the commandline option that NDK will use for gcc: even for the ARMv7 ABI it will be -mfloat-abi=softfp >It's not clear from the documents whether >all androidabi-v7a devices are required to have a VFP I understand the section in the quoted document above to mean that VFP is mandatory for the armeabi-v7a ABI, and NEON is optional. But yeah, the wording could be more precise. >and whether their GCC port defaults to hardfp >generation. See above. GCC may technically allow to set the hardfloat ABI on the commandline in the NDK build of gcc, but all the runtime libs in the NDK are soft float ABI. So no hardfloat ABI support in the NDK and Android versions targeted by the official NDK!!! >It's almost getting back to the early days of SUN when every >workstation had a different FPU. Indeed, the ARM-world is very modular and full of variants, and it's not just floating point : e.g. one other CPU feature that needs to be treated with care is the "Thumb" instruction set which can be used to minimise code size, but is not supported by all devices. Cheers HB ----------------------------------------------------------------- Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: Eric J Korpela <[email protected]> To: "[email protected]" <[email protected]>, Date: 07/23/2013 03:14 AM Subject: [boinc_dev] ARM questions Sent by: "boinc_dev" <[email protected]> In the both the android and the general ARM discussion I'm suffering from a bit of confusion, and I'm hoping that someone can tell me whether I'm getting this right... There are two floating point ABIs for arm-linux corresponding to the calling conventions used for passing floating point parameters (memory vs registers, I presume). These are somewhat independent of whether a hardware FPU is used. Here's where I start to get confused. Tell me if I've got this right. The gcc default is to use the soft float ABI, which results in the generation of calls to implement emulations of floating point path. If one specifies -mfloat-abi=softfp the compiler generates hardware floating point instructions but uses the softfp call convention. If a program of this type is run without a VFP present it generates a illegal instruction exception and the program quits, rather than there being an VFP emulator that catches the exception and emulates the code. These two types of code can be mixed. The hard float is chosen by -mfloat-abi=hard. For this a VFP is required, but it is the most efficient mode. FFTW 3.3.3, for some reason, thinks this mode is incompatible with NEON SIMD code, though. So if I wanted to target the widest variety of devices. I'd make one executable with the default (software) FP. I'd make one with softfp including NEON code in FFTW. And I'd make one for hardfp without NEON code in FFTW. I hope there's something in the BOINC headers or host record that would tell me which one to send. Android throws in another twist in that pre-ARMv7 devices can only use software floating point. It's not clear from the documents whether all androidabi-v7a devices are required to have a VFP or whether it's still optional and whether their GCC port defaults to hardfp generation. It's almost getting back to the early days of SUN when every workstation had a different FPU. Even with software float a phone is faster than a Sun-2, though. Anyhow, if anyone wants to clear up my misconceptions, please do. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
