ARM Compatibility: Binary Translation

Similar to Apple's move from PowerPC to x86, Intel finds itself in a difficult position with bringing Atom to Android. The OS isn't an issue as it has already been ported to x86 and all further releases will be available in both ARM and x86 flavors. The bigger problem is application compatibility.

There's already support for targeting both ARM and x86 architectures in the Android NDK so anything developed going forward should be ok so long as the developer is aware of x86.

Obviously the first party apps already work on x86, but what about those in the Market?

By default all Android apps run in a VM and are thus processor architecture agnostic. As long as the apps are calling Android libraries that aren't native ARM there, once again, shouldn't be a problem. Where Intel will have a problem is with apps that do call native libraries or apps that are ARM native (e.g. virtually anything CPU intensive like a 3D game).

Intel believes that roughly 75% of all Android apps in the Market don't feature any native ARM code. The remaining 25% are the issue. The presumption is that eventually this will be a non-issue (described above), but what do users of the first x86 Android phones do? Two words: binary translation.

Intel isn't disclosing much about the solution, but by intercepting ARM binaries and translating ARM code to x86 code on the fly during execution Intel is hoping to achieve ~90% app compatibility at launch. Binary translation is typically noticeably slower than running native code, although Intel is unsurprisingly optimistic about the experience on Android. I'm still very skeptical about the overall experience but we'll have to wait and see for ourselves.


What's Different This Time Around: Google & A Sweet Reference Platform Final Words


View All Comments

  • french toast - Sunday, January 15, 2012 - link

    You dumbass, cant you see it has got nothing to do with that, its the VERSION that the phones run on and then compared against...2.3.7 is much faster than 2.3.3 or make it an equal fair test you would have to run EQUAL software.

    You would also have to do a number of different tests that stress the cpu under LOAD, then measure the power consumption.

    Anand has taken some very biased intel run power slides and benched these phones on limited single thread benchmarks, and yes it shows an advantage, BUT that could just be the android version its self, not representitive of medfield superiority.

    Add to that the fact that Atom runs alot faster per core and only slightly beats old hardeware on such single thread tests like caffeinemark, and looses others on quadrant and antutu, as well as offering worse gpu performance than a galaxy s2, note, and iphone 4s that were released mid last year on 40nm.

    Krait on 28nm with on die 4g in quadcore configuerations and with a next gen 320 gpu will release THIS year about the time Intel releases a chip that is barley competitive with chips LAST year.
  • baros - Monday, January 16, 2012 - link

    Why didn't intel go with meego instead ? Reply
  • diulaylomochohai - Wednesday, April 25, 2012 - link

    Why did the battery test omit numbers from HTC 1S and 1X? Reply
  • jaffa62 - Wednesday, May 16, 2012 - link

    Typical smartphone malware leverages platform vulnerabilities that allow it to gain root access on the device in the background. Using this access the malware installs additional software to target communications, location, or other personal identifying information. Thanks.

Log in

Don't have an account? Sign up now