page.title=x86 Support
@jd:body
The NDK includes support for the {@code x86} ABI, which allows native code to run on
Android-based devices running on CPUs supporting the IA-32 instruction set.
Overview
To generate x86 machine code, add {@code x86} to the {@code APP_ABI} definition in your
{@code Application.mk} file. For example:
APP_ABI := armeabi armeabi-v7a x86
For more information about defining the {@code APP_ABI} variable, see
{@code Application.mk}.
The build system places generated libraries into {@code $PROJECT/libs/x86/}, where
{@code $PROJECT} represents your project's root directory, and embeds them in your APK under
{@code /lib/mips/}.
The Android package extracts these libraries when installing your APK on a compatible x86-based
device, placing them under your app's private data directory.
In the Google Play store, the server filters applications so that a consumer sees only the native
libraries that run on the CPU powering his or her device.
x86 Support for ARM NEON Intrinsics
Support for ARM NEON intrinsics is provided in the form of C/C++ language headers with the same
name as the standard ARM NEON intrinsics header, {@code arm_neon.h}. These headers are available for
all NDK x86 toolchains. They translate NEON intrinsics to native x86 SSE ones.
Characteristics of this solution include the following:
- Default use of SSE through SSSE3 for porting ARM NEON to Intel SSE, covering ~93%
(1869 of total 2009) of all NEON functions.
- Redefinition of ARM NEON 128 bit vectors into the equivalent x86 SIMD data.
- Redefinition of some functions from ARM NEON to Intel SSE if a 1:1 correspondence exists.
- Implementation of some ARM NEON functions using Intel SIMD if it will yield a performant result.
- Implementation of some of the remaining NEON functions using the serial solution, and issuing
the corresponding "low performance" compiler warning.
Performance
In most cases, you should be able to attain performance similar to what you would get from ARM
NEON code. Recommendations for best results include:
- Use 16-byte data alignment for faster load and store.
- Avoid using constants with NEON functions. Using constants results in a performance penalty due
to having to load constants. If you must use constants, try to initialize them outside of hotspot
loops. If possible, replace them with logical and compare operations.
- Try to avoid functions marked as "serially implemented" because they need to store data from
registers to memory. Instead, process them serially and reload them. You may be able to change the
data type or algorithm used to vectorize the whole port instead of leaving it as a serial one.
For more information on this topic, see
From ARM NEON to Intel SSE– the automatic porting solution, tips and tricks.
Known differences from ARM version
In the great majority of cases, x86 implementations produce the same results as ARM
implementations for NEON. x86 implementations pass
NEON tests nearly 100% of the
time. Still, there are several corner cases in which an x86 implementation produces results
different from its ARM counterpart. Known incompatibilities are as follows:
- {@code VRECPS/VRECPSQ}
If one of the operands is +/- infinity and the second is +/- 0.0:
- {@code VRSQRTS/VRSQRTSQ}
If one of the operands is +/- infinity and the second is +/- 0.0:
- {@code VMAX/VMAXQ}
If one of the operands is NaN, or both operands are +/- 0.0:
- On ARM CPUs, floating-point maximum works as follows:
- max(+0.0, -0.0) = +0.0.
- If any input is a NaN, the corresponding result element is the default NaN.
To learn more about this condition and result, see the
ARM Compiler toolchain Assembler Reference, ignoring the "Superseded" watermark.
- On x86 CPUs, floating-point maximum works as follows:
- If one of the source operands is NaN, then return the second source operand.
- If both source operands are equal to 0, then return the second source operand.
For more information about these conditions and results, see Volume 1 Appendix E chapter
E.4.2.3 and Volume 2, p 3-488, of the
Intel® 64 and IA-32 Architectures Software Developer’s
Manual.
- {@code VMIN/VMINQ}
If one of the operands is NaN or both are +/- 0.0:
- On ARM CPUs floating-point minimum works as follows:
- min(+0.0, -0.0) = -0.0.
- If any input is a NaN, the corresponding result element is the default NaN.
To learn more about this condition and result, see the
ARM Compiler toolchain Assembler Reference, ignoring the "Superseded" watermark.
- On x86 CPUs floating-point minimum works as follows:
- If one of the source operands is NaN, than return the second source operand.
- If both source operands are equal to 0, than return the second source operand.
For more information about these conditions and results, see Volume 1 Appendix E chapter
E.4.2.3 and Volume 2, p 3-497, of the
Intel® 64 and IA-32 Architectures Software Developer’s
Manual.
- {@code VRECPE/VRECPEQ}
These instructions provide different levels of accuracy on ARM and x86 CPUs. For more information
about these differences, see
How do I use VRECPE/VRECPEQ for reciprocal estimate? on the ARM website, and Volume 2, p.
4-281 of the
Intel® 64 and IA-32 Architectures Software Developer’s Manual.
- {@code VRSQRTE/VRSQRTEQ}
Sample code
In your project make sure to include the {@code arm_neon.h} header, and define include
{@code x86} in your definition of {@code APP_ABI}. The build system then ports your code to x86.
For an example of how porting ARM NEON to x86 SSE works, see the hello-neon sample.
Standalone Toolchain
You can incorporate the {@code x86} ABI into your own toolchain. For more information, see
Standalone Toolchain.
Compatibility
x86 support requires, at minimum, Android 2.3 (Android API level 9). If your project files
target an older API level, but include x86 as a targeted platform, the NDK build script
automatically selects the right set of native platform headers/libraries for you.