Shulou(Shulou.com)06/01 Report--

This article mainly introduces "what is the difference between cross-compiler arm-linux-gnueabi and arm-linux-gnueabihf". In daily operation, I believe that many people have doubts about the difference between cross-compiler arm-linux-gnueabi and arm-linux-gnueabihf. The editor consulted all kinds of materials and sorted out simple and useful operation methods. I hope it will be helpful to answer the question of "what is the difference between cross-compiler arm-linux-gnueabi and arm-linux-gnueabihf"! Next, please follow the editor to study!

one。 What are ABI and EABI?

1) ABI: binary application program interface (Application Binary Interface (ABI) for the ARM Architecture)

In a computer, the application binary interface describes the low-level interface between the application (or other type) and the operating system or other applications.

ABI covers a variety of details, such as:

Size, layout, and alignment of data types

Calling conventions (which control how the parameters of the function are passed and how the return values are accepted), for example, whether all parameters are passed through the stack or some parameters are passed through registers; which register is used for which function parameters; and whether the first function parameter passed through the stack is the first push to the stack or the last

The coding of system calls and how an application makes system calls to the operating system

And in a complete operating system ABI, the binary format of object files, libraries, and so on.

A complete ABI, like the Intel binary compatibility Standard (iBCS), allows programs on operating systems that support it to run without modification on other operating systems that support this ABI.

Unlike the application program interface (API), ABI defines the interface between source code and libraries, so the same code can be compiled in any system that supports this API, and ABI allows compiled object code to run without change in systems that use ABI compatibility.

2) EABI: embedded ABI

The embedded application binary interface specifies standard conventions for file format, data type, register usage, stacking organization optimization, and parameters in an embedded software.

Developers can also use EABI as an interface to assemble languages generated by compatible compilers using their own assembly language.

EABI-enabled compilers can create object files that are compatible with code generated using similar compilers, allowing developers to link to a library generated by different compilers.

The main differences between EABI and ABI for general-purpose computers are that privileged instructions are allowed in application code, dynamic linking is not required (sometimes prohibited), and a more compact stack frame organization is used to save memory. Power PC and ARM are widely used in EABI.

two。 Two cross compilers related to gnueabi: gnueabi and gnueabihf

The two cross compilers in the debian source 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 the two cross-compilers are suitable for two different architectures, armel and armhf. Armel and armhf adopt different strategies for floating-point operations (only arm with fpu can support these two floating-point strategies).

In fact, the two cross-compilers are just gcc options-the default values of mfloat-abi are different. Gcc's option-mfloat-abi has three values of soft,softfp,hard (the latter two require fpu floating-point units in arm, soft is compatible with the latter two, but softfp and hard modes are not compatible with each other):

Soft: do not use fpu for floating-point calculations, even if there is a fpu floating-point unit, but use software mode.

Softfp: the default value used in the armel architecture (the corresponding compiler is gcc-arm-linux-gnueabi) is calculated by fpu, but the parameters are passed in ordinary registers, so when interrupts, only ordinary registers need to be saved, and the interrupt load is small, but the parameters need to be converted to floating-point recalculation.

Hard: the default value used by the armhf architecture (the corresponding compiler gcc-arm-linux-gnueabihf) is calculated by fpu, and the parameters are also passed by the floating-point register in fpu, which omits the conversion and has the best performance, but the interrupt load is high.

Save the contents of the c file used by the following tests as mfloat.c

# include

Int main (void)

{

Double a,b,c

A = 23.543

B = 323.234

C = BBG a

Printf ("the 13 Compact 2 =% f\ n", c)

Printf ("hello world!\ n")

Return 0

}

1) compile with arm-linux-gnueabihf-gcc and use the "- v" option to get 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 the use of 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 that the softfp mode is used.

three。 Expand reading

The following describes the differences between soft floating point (soft-float) and hard floating point (hard-float) compilation and link implementation of ARM code at compile time. From the introduction of VFP floating point unit to the concept of soft floating point (soft-float) and hard floating point (hard-float)

VFP (vector floating-point)

Since ARMv5, there have been optional Vector Floating Point (VFP) modules, and of course the latest ones such as Cortex-A8, Cortex-A9 and Cortex-A5 can be configured without VFP for chip vendors to choose from.

After several years of development, VFP has VFPv2 (some ARM9 / ARM11), VFPv3-D16 (using only 16 floating-point registers, the default is 32), and VFPv3+NEON (such as most Cortex-A8 chips). For ARM chips containing NEON, NEON 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) for execution. FPU usually has an extra set of registers to perform floating-point parameter passing and operations.

Using the actual hardware floating-point unit FPU will certainly lead to a performance improvement. 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 floating-point function calls and library function calls, with no instruction calls from FPU and no parameter transfer from floating-point registers. Floating-point parameters are also passed through ARM registers or stacks.

The default compilation of today's Linux systems is to use hard-float, which generates illegal instructions and exceptions even if the system does not have any floating-point processor units. Therefore, general system images use soft floating points to be compatible with processors without VFP.

Armel ABI and armhf ABI

In armel, there are three conventions for floating-point calculations. Take gcc as an example, there are three corresponding-mfloat-abi parameter values: soft,softfp,hard.

Soft means that all floating-point operations are implemented in the software layer. Of course, the efficiency is not high, and there will be unnecessary floating-point to integer and integer-to-floating-point conversion. It is only suitable for early ARM processors without floating-point computing units.

Softfp is currently the default setting for armel. It hands floating-point calculations to FPU, but function parameters are passed using general integer registers instead of FPU registers.

Hard uses FPU floating-point registers to pass function parameters to FPU processing.

It should be noted that soft is compatible with the latter two in terms of compatibility, but softfp and hard modes are not compatible.

By default, armel uses softfp, so the armel of hard mode is treated as a separate abi, called armhf.

Using the hard mode, you can save an average of 20 CPU cycles per floating-point related function call. For an architecture like ARM, which is important for every cycle, this improvement is undoubtedly huge.

Using armhf can get a performance improvement of 20% Murray 25% on some applications without changing the source code and configuration at all. For some programs that rely heavily on floating-point operations, the performance can be improved by 300%.

Compilation options for Soft-float and hard-float

On the compilation parameters of CodeSourcery gcc, use-mfloat-abi=name to specify how floating-point operations are handled. -mfpu=name to specify the type of floating point coprocessing.

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, etc.

Use-mfloat-abi=hard (equivalent to-mhard-float)-mfpu=vfp to choose to compile to a hard floating point. Using-mfloat-abi=softfp can be compatible with the hardware with VFP and the software implementation of soft-float. The runtime connector ld.so will choose the operation unit when performing floating-point operations.

Whether it is a direct hardware call or a library function call, whether to execute the libm under / lib or / lib/vfp. -mfloat-abi=soft (equivalent to-msoft-float) calls the soft floating-point implementation library directly.

Under the ARM RVCT toolchain, define the fpu schema:

-fpu softvfp

-fpu softvfp+vfpv2

-fpu softvfp+vfpv3

-fpu softvfp+vfpv_fp16

-fpu softvfp+vfpv_d16

-fpu softvfp+vfpv_d16_fp16.

Define floating point operation types

-fpmode ieee_full: the precision of all single-precision float and double-precision double should be consistent with the IEEE standard, and the specific mode can be specified dynamically at run time

-fpmode ieee_fixed: rounded to the nearest implementation of the IEEE standard without imprecise exceptions

-fpmode ieee_no_fenv: the IEEE standard rounded to the nearest implementation, without exception

-fpmode std: IEEE standard with non-specification number flush to 0 and rounded to the nearest implementation without exception

-fpmode fast: for more aggressive optimization, there may be a slight loss of accuracy.

At this point, the study on "what is the difference between cross-compiler arm-linux-gnueabi and arm-linux-gnueabihf" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.