ARMvX?

[Espen Riskedal]

On Tue, Jul 19, 2011 at 9:49 PM,  <thomas.senyk at nokia.com> wrote:
> Ah I see.
>
> This document helped me understand that Android has a solid definition (hadn't expected that) of what ABI versions it supports.
> Now everything makes a lot more sense :)

I agree, this was an eye opener. I think "CPU-ARCH-ABIS.html" should
be required reading now! :D

Summarized, at the moment there are three ABIs (this is from NDK v6b):

"armeabi"
- ARMv5TE instructions
- no HW floating points
- Thumb-1 (or ARM)

"armeabi-v7a"
- extends and is compatible with armeabi
- adds ARM Architecture v7-a instructions
- adds Thumb-2
- adds HW floating points (vfpu) but calling conventions are kept
compatible with armeabi
- optionally adds: NEON and friends (should be detected at runtime)

"x86"
- Pentium Pro instruction set
- MMX, SSE, SSE2 and SSE3 instruction set extensions

My question then is, why do we plan to build for a lot more
variations? On Linux NEON is detected at runtime, but we're planning
non-NEON and NEON builds. Why?

Another part that explained a lot to me:

"It is also possible to build machine code for *two* distinct ABIs by using:

   APP_ABI := armeabi armeabi-v7a

This will instruct the NDK to build two versions of your machine code: one for
each ABI listed on this line. Both libraries will be copied to your application
project path and will be ultimately packaged into your .apk.

Such a package is called a "fat binary" in Android speak since it contains
machine code for more than one CPU architecture. At installation time, the
package manager will only unpack the most appropriate machine code for the
target device. See below for details."

Let's hope Apple doesn't sue them for stealing the Universal binaries concept :D

espen