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
POST A COMMENT

163 Comments

View All Comments

  • guilmon19 - Tuesday, January 10, 2012 - link

    http://www.brightsideofnews.com/news/2011/5/19/the...

    brightside actually does a very nice benchmark and analysis on the memory bandwith problem that arm has.
    Reply
  • Exophase - Tuesday, January 10, 2012 - link

    That was with an old i.MX51. The situation is different with newer Cortex-A9 SoCs, especially where the SoC designer didn't botch the main memory latency. Reply
  • grrrrr - Wednesday, January 11, 2012 - link

    intel = FAKEEEEEE
    BOOOOOOO
    Reply
  • Hector2 - Wednesday, January 11, 2012 - link

    grow up Reply
  • shaolin95 - Wednesday, January 11, 2012 - link

    what an awesome comment...what are you 5? Reply
  • Stuka87 - Thursday, January 12, 2012 - link

    Shouldn't that be "FAAAAAAKE" as the 'e' is silent. So extending the 'e' out like that has no change on the sound of the word.

    If you are going to troll, at least do it properly.
    Reply
  • chiddy - Sunday, January 15, 2012 - link

    +1 Reply
  • Morg. - Wednesday, January 11, 2012 - link

    ARM's memory problem ???

    Year-old 40+nm parts are slightly slower than brand new Intel 32nm ?

    yes arm has a memory problem indeed ..

    the real market situation for medfield will probably be a LOT different and as usual Intel will still get some market space thanks to murky deals and stuff :p
    Reply
  • guilmon14 - Wednesday, January 11, 2012 - link

    I wasn't trying to dis ARM what i meant to show, with the link, is that ARM A8 cpu performance would be just as, if not more, then the current atom if it had similar memory performance. Reply
  • blazermaniac - Saturday, January 14, 2012 - link

    murky deals...? Reply

Log in

Don't have an account? Sign up now