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

164 Comments

View All Comments

  • Griswold - Thursday, January 12, 2012 - link

    How is "too little too late" going to help Intel? By the time products with this trash flock to market, it'll be up against A15 and look like the thing from yesteryear it really is.. Reply
  • iwod - Tuesday, January 10, 2012 - link

    It was always only a matter of time before Intel get a x86 CPU with their superior manufacturing down to ARM SoC level.

    And since new science discovery is pushing Moores Law's Limit further and further away, intel has a much better fighting chance.

    The problem is how much does an Intel SoC cost compare to a reference design ARM made SoC in TSMC?
    Reply
  • Griswold - Thursday, January 12, 2012 - link

    Come back in a year and ask again... thats when this hits the shelves. Reply
  • Computer Bottleneck - Tuesday, January 10, 2012 - link

    Thank you for the article!

    Is there any chance we could see a teardown and analysis of the Intel Medfield reference design platform in the next 6 months?

    I think it would be very interesting to compare Intel's progress in chip integration over the next few years. (ie, Compare Medfield reference platform to Silvermont reference platform to Airmont reference platform, etc)
    Reply
  • jwcalla - Tuesday, January 10, 2012 - link

    I just got an ulcer thinking about how Android fragmentation is going to be taken to a whole new level.

    "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."

    heh

    right

    That's sunshine and lollipops right there.

    It isn't enough to worry about 4,000 different CPUs and five active versions of the OS, but now we have to worry about two completely incompatible instruction sets too. All for the glory of producing apps that make no money on this platform. Suddenly iOS seems even more attractive.
    Reply
  • hechacker1 - Wednesday, January 11, 2012 - link

    It's only niche apps that require specific machine code that won't work. Otherwise the interpreted bytecode should just work.

    It's similar to when Apple moved from PPC to x86. You just had to recompile the program with the new toolchain and it would create a universal binary. Except here, it isn't even necessary to recompile the majority of the time.

    If anything, with the introduction of Android 4.0, we will finally have a common base for phones, tablets, and the one or two smart TVs. Sure it will require an upgrade for most users stuck on older unsupported Android versions, but that will come with time.
    Reply
  • nofumble62 - Wednesday, January 11, 2012 - link

    the difference now is all about peripheral and IO design. The ARM advantage has shrinken to almost zero. Reply
  • tipoo - Wednesday, January 11, 2012 - link

    Shrunken. Sorry. Reply
  • dealcorn - Wednesday, January 11, 2012 - link

    ARM earned it's dominance of the mobile space with affordable, superior power efficiency. Now, Intel waltz's in with a 5 year old design for a space it used to know nothing about and it has superior power efficiency. Is there some reason to think this is in any way not a replay of the old Intel vs RISC story?

    It is hard to take ARM seriously when Intel's old design from a period when it was generally clueless is superior to what ARM markets today. However, we would not be here without ARM's historic contribution. Also, the market for garage door openers is not going away.
    Reply
  • aury - Wednesday, January 11, 2012 - link

    "superior power efficiency"

    how is this chip superior, itt uses more power than Samsungs old A9 cortex, and Samsung's implementation isn't even the the most power efficient, let alone that the A9 is an old chip to begin with
    Reply

Log in

Don't have an account? Sign up now