Android ARM6/7 and VFP/NEON

[petr.m...@mautilus.com]

I would like to understand more the CPU used on Android phones. The
reason is that we are building the C library which has the certain CPU/
math processor architecture flags we can set.

1.

So far we have found that all Android devices CPUs are ARM
design and are either ARM6 (older devices, low ends, Huawei, ZTE,
small SE) or ARM7 (Honeycomb tablets and all more expensive devices,
almost all with resolution WVGA and higher)I have checked ~20 devices
and all have processor of that type. Is that correct? Are there some
others?
2.

Now when it comes to the multimedia and mathematical operations
I think two units are important – the VFP for floating point
arithmetic and the SIMD - NEON. After testing the above mentioned
group of devices I have found that VFP support is in almost all
devices, while NEON not. Any comments to that?
3.

I do not know what exactly is the ARM6 and ARM7 difference
(besides the speed in general). Now we are building a multimedia C
library, which has couple of flags for building. My question is how to
target the largest number of devices on one side and how to allow the
users of the better devices to use their hardware. My proposal is to
prepare 3 distinct builds: ARM6/VFP, ARM7/VFP and ARM7/VFP/NEON. Other
proposals?
4.

The ARM6/VFP I think should run on all configurations, except
devices, which are missing the VFP (e.g. the old HTC Wildfire) – but
those will remain unsupported.

Is this a good approach? Any comments are welcomed.

Regards, STeN

[Marco Bernasocchi]

Hi,
You can easily package code for two armV in the sae package, just create 2 directories (armeabi and armeabi-v7a) in the yourAPK/libs directory and put the libs there. As per docs, the ndk supports those two architectures and the devices will automatically choose the best one.
I would (and do in https://github.com/qgis/qgis-android/) build all libs for v5 which are supported on almost all devices and then for v7.
The problem is with neon. I don't know how you could have two V7 libs directory.
anyhow, the ndk has some good pointers.
Let us know if you find a solution.
ciao

[David Turner]

First, be aware that there is a slight difference in the way ARM names its CPUs and its architectures

• ARMv5, ARMv6 and ARMv7 refer to CPU Architectures, i.e. supported instruction sets. Note the little 'v' here, it matters.

• ARM6/ARM7/ARM9/etc... are names for old CPUs that did implement very old version of the architecture (e.g. ARMv3 or is it ARMv4).

Each Architecture version has two groups of instructions:

• mandatory instructions that must be supported by all CPUs that implement the architecture

• optional instruction "extensions" that implement additional capabilities, but are not required by the architecture.

This means that two ARMv6 CPUs might not support the same instructions, depending on the exact implementation of the architecture they support. For the sake of simplicity, we will ignore performance differences as well.

Fortunately, all ARMv5 mandatory instructions are part of all ARMv6 mandatory instructions, which are themselves part of all ARMv7 mandatory instructions. This is good because it means that 'armeabi' binaries can essentially run on any of these CPUs.

There are several "instruction set extension" in the ARM world, the most important one is called "VFP", and provides for hardware-accelerated FP operations. Note that there are several variants of VFP though:

• VFPv1, now completely obsolete, let's forget about this one.

• VFPv2, is only supported by some ARMv6 CPUs, but not all (it's optional)
  
  
• VFPv3-D16, is supported by *all* ARMv7 CPUs (mandatory), but no ARMv6 CPU. That's because VFPv2 and VFPv3 are *not* binary compatible.
  
  
• VFPv3-D32, is the same than VFPv3-D16, except that it provides 32 FP registers, instead of 16. Only supported by some ARMv7 CPUs
  
  
• NEON, is VFPv3-D32 plus a bunch of handy SIMD instruction that can perform integer and floating point operations in parallel. Only supported by some ARMv7 CPUs.

Note that there is also another extension related to "DSP" or "media" processing instructions. These are different than any version of VFP, and completely optional too, though they can be part of ARMv5, ARMv6 or ARMv7 CPUs.

So to answer your specific questions:

• It is likely that all Android devices on the Market are either ARMv6 or ARMv7 based. However, you can't rule out that some of them are ARMv5 though (or more precisely, ARMv5TE, which is the minimum supported by Android, which means ARMv5 + Thumb-1 + a few other optional instructions).

• Whether these ARMv5 / ARMv6 support DSP or VFP is completely optional. You can't even guarantee that all ARMv6 devices support VFPv2.
  Remember that VFPv2 is not binary compatible with VFPv3, so don't expect such machine code to run on an ARMv7 CPU .
  
  
• All ARMv7 devices support VFPv3 (or more precisely VFPv3-D16). Some of them also support NEON (which requires VFPv3-D32). I am not aware of any ARMv7 device that only supports VFPv3-D32 and not NEON. Moreover, GCC doesn't allow you to generate that machine code (it assumes only VFPv3-D16 or NEON are supported).

Also, note that VFPv2 machine code generation with the Android toolchain has never been tested, so we can't guarantee that this would work. You will probably have to use inline assembly to make this work (again, no guarantees on the capabilities of the GNU assembler here).

Generally speaking, it's better to provide a binary that can run on as many devices as possible, using runtime CPU features probing to determine the best code path to use at runtime. The NDK provides a tiny static helper library to do that (named "cpufeatures").

If you can't do that, you'll have to whitelist devices on the Android Market (and any other distribution channel you intend to use for your program).

Hope this helps

- David

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Marco Bernasocchi]

Hi David, thanks a lot for rhe explanation. So deploying apks with armeabi and armeabi-v7a would be the correct way to target as many devices as possible while still allowing for optimized code? The only problem then would be how to add neon support.
I ve a lot of big external libs like geos, spatialite, gdal and iconv which I don't really want do patch to use cpufeatures to detect neon. So I guess the only way would be to create a separate package for neon supporting devices?
thanks