Cross-compiler differences between Arm-linux-gnueabi and ARM-LINUX-GNUEABIHF

I have not been able to understand the two cross-compiler exactly what the problem, deliberately Google, summed up as follows, hoping to help the road and I have the same confused brother ....

First. What is ABI and Eabi
1) ABI: Binary Application Interface (application binary Interface (ABI) for the ARM Architecture)
In computers, applying a binary interface describes a low-level interface between an application (or other type) and an operating system or another application.
The ABI covers a variety of details, such as:
The size, layout, and alignment of the data type;
The calling convention (which controls how the parameters of a function are routed and how the return value is accepted), for example, whether all arguments are passed through the stack, or some of the parameters are passed through the register, which register is used for which function parameters, and the first function parameter passed by the stack is first pushed to the stack or the last;
The encoding of the system call and how an application makes system calls to the operating system;
And in a full operating system ABI, the binary format of the target file, the library, and so on.
A complete ABI, like the Intel Binary Compatibility Standard (IBCS), allows programs on the operating system that support it to run without modification on other operating systems that support this ABI.
The ABI differs from the application interface (API), where the API defines the interface between the source code and the library, so the same code can be compiled in any system that supports the API, and the ABI allows the compiled target code to run without changes in the system using the compatible ABI.

2) EABI: Embedded ABI
Embedded application binary interfaces specify standard conventions for file formats, data types, register usage, stacked organization optimizations, and parameters in an embedded software.
Developers using their own assembly language can also use Eabi as an interface to the assembly language generated by the compatible compiler.
The target file created by the compiler that supports Eabi can be compatible with code generated by a similar compiler, allowing the developer to link a library generated by a different compiler.
The main difference between Eabi and ABI on general-purpose computer is that privileged instructions are allowed in application code, do not require dynamic linking (sometimes forbidden), and more compact stack frames are used to save memory. Power PC and arm are widely used in Eabi.

Second. Gnueabi related two cross compilers: Gnueabi and GNUEABIHF
In the Debian source these two cross compilers are defined as follows:
Gcc-arm-linux-gnueabi–the GNU C compiler for Armel architecture
Gcc-arm-linux-gnueabihf–the GNU C compiler for ARMHF architecture
It can be seen that these two cross compilers are suitable for Armel and ARMHF two different architectures, Armel and ARMHF have different strategies for floating-point operations (with the FPU arm to support both floating-point arithmetic strategies)

In fact, these two cross compilers are only GCC's option-mfloat-abi the default values are different. The GCC option-mfloat-abi has three values Soft,softfp,hard (both of which require an FPU floating point unit in arm, soft is compatible with the latter, but SOFTFP and hard two modes are incompatible):
Soft: Use the software mode instead of the FPU for floating point calculations, even if the FPU floating point unit is not used.
The default value of the Softfp:armel architecture (corresponding compiler for Gcc-arm-linux-gnueabi) is calculated using the FPU, but the parameters are transmitted by ordinary registers, so when the interrupt is done, only the ordinary registers are saved, the interrupt load is small, But the parameters need to be converted to floating-point recalculation.
The default value of the HARD:ARMHF architecture (corresponding compiler GCC-ARM-LINUX-GNUEABIHF) is calculated using the FPU, and the parameters are also transmitted using the floating-point registers in the FPU, eliminating the need for conversions with the best performance, but with high interrupt loads.

Save the contents of the C file used in the following test to MFLOAT.C:
#include <stdio.h>
int main (void)
{
Double a,b,c;
A = 23.543;
b = 323.234;
c = b/a;
printf ("The 13/2 =%f\n", c);
printf ("Hello World!\n");
return 0;
}

1) compile with ARM-LINUX-GNUEABIHF-GCC and use the "-V" option for more detailed information:
# arm-linux-gnueabihf-gcc-v Mfloat.c
collect_gcc_options= '-V '-march=armv7-a '-mfloat-abi=hard '-mfpu=vfpv3-d16′ '-mthumb '
-mfloat-abi=hard, you can see using hard hardware floating-point mode.

2) compile with ARM-LINUX-GNUEABI-GCC:
# arm-linux-gnueabi-gcc-v Mfloat.c
collect_gcc_options= '-V '-march=armv7-a '-mfloat-abi=softfp '-mfpu=vfpv3-d16′ '-mthumb '
-MFLOAT-ABI=SOFTFP, you can see the use of SOFTFP mode.

Third. Expand Reading
The following illustrates the differences in the compilation of soft floating-point (soft-float) and hard floating-point (hard-float) when arm code is compiled, and when linking is implemented. Concepts from the introduction of VFP floating-point units to soft floating-point (soft-float) and hard floating-point (hard-float)

VFP (vector floating-point)
From ARMV5 onwards, there is an optional Vector floating point (VFP) module, of course, the latest such as Cortex-a8, CORTEX-A9 and CORTEX-A5 can be configured without VFP for the chip manufacturers to choose.
After several years of development, VFP has VFPv2 (some arm9/arm11), vfpv3-d16 (use only 16 floating-point registers, default is 32) and Vfpv3+neon (such as most cortex-a8 chips). For ARM chips that contain neon, neon general and VFP common registers.

Hard floating-point hard-float
The compiler compiles the code directly to the hardware floating-point coprocessor (floating-point unit FPU) to execute. The FPU usually has a set of additional registers to complete the floating-point parameter transfer and operation.
Using the actual hardware floating-point unit FPU will of course bring a performance boost. Because often a floating-point function call requires several or dozens of clock cycles.

Soft floating-point soft-float
The compiler converts floating-point operations into function calls and library function calls of floating-point operations, without an instruction call from the FPU, and without the parameter passing of a floating-point register. The transfer of floating-point parameters is also done through arm registers or stacks.
Now the Linux system default compilation chooses to use Hard-float, even if the system does not have any floating-point processor units, this will result in illegal instructions and exceptions. Therefore, the general system image uses soft floating point to be compatible with the processor without VFP.

Armel Abi and ARMHF Abi
in Armel, there are three conventions about floating-point calculation. In the case of GCC, the corresponding-mfloat-abi parameter values are three: Soft,softfp,hard.
Soft refers to all floating-point operations are implemented in the software layer, the efficiency of course is not high, there will be unnecessary floating-point to Integer, integer-to-floating conversion, only suitable for the early non-floating-point computing unit of ARM processor;
SOFTFP is the default setting for the current Armel. It gives a floating-point calculation to the FPU, but the pass-through of the function parameter uses a generic integer register instead of the FPU register, and
Hard uses the FPU floating-point register to pass the function arguments to the FPU processing.
It is important to note that soft is compatible with the latter in compatibility, but SOFTFP and hard two modes are incompatible.
By default, Armel uses SOFTFP, so the Armel of hard mode is used as an ABI alone, called ARMHF. The
uses hard mode to save 20 CPU cycles on average for each floating-point correlation function call. For an architecture that is important to each cycle of arm, this increase is undoubtedly huge.
with no change in source code and configuration at all, on some applications, the use of ARMHF can get 20%--25% performance gains. For some programs that rely heavily on floating-point arithmetic, it is possible to achieve a 300% performance boost.

Compilation options for Soft-float and Hard-float
On the codesourcery GCC compilation parameters, use-mfloat-abi=name to specify how floating-point arithmetic is handled. -mfpu=name to specify the type of floating-point coprocessor.
Optional types such as FPA,FPE2,FPE3,MAVERICK,VFP,VFPV3,VFPV3-FP16,VFPV3-D16,VFPV3-D16-FP16,VFPV3XD,VFPV3XD-FP16,NEON,NEON-FP16, Vfpv4,vfpv4-d16,fpv4-sp-d16,neon-vfpv4 and so on.
Use-mfloat-abi=hard (equivalent to-mhard-float)-MFPU=VFP to choose to compile to hard floating point. Using-MFLOAT-ABI=SOFTFP can be compatible with VFP hardware and soft-float software implementation, the runtime connector ld.so will perform floating point operation for the selection of the unit of operation,
Whether it is a direct hardware call or a library function call, whether it is executing/lib or/LIB/VFP libm. -mfloat-abi=soft (equivalent to-msoft-float) calls the soft floating-point implementation library directly.

Under the Arm RVCT tool chain, define the FPU mode:
–FPU SOFTVFP
–FPU Softvfp+vfpv2
–FPU Softvfp+vfpv3
–FPU SOFTVFP+VFPV_FP16
–FPU Softvfp+vfpv_d16
–FPU softvfp+vfpv_d16_fp16.

Defining floating-point operation types
–fpmode Ieee_full: The precision of all single-precision float and double-precision double is consistent with the IEEE standard, the specific mode can be specified dynamically at runtime;
–fpmode ieee_fixed: Rounded to the nearest implementation of the IEEE Standard, with no imprecise anomalies;
–fpmode ieee_no_fenv: Rounded to the nearest implementation of the IEEE Standard, without exception;
–fpmode std: Non-specification flush to 0, rounded to the nearest implementation of the IEEE Standard, without exception;
–fpmode fast: More aggressive optimizations may be a bit of a loss of precision.

Remember don ' t at a loss and let the brain to calm down when comes questions, so can solve them faster!

Cross-compiler differences between Arm-linux-gnueabi and ARM-LINUX-GNUEABIHF