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
Comments Locked

164 Comments

View All Comments

  • extide - Wednesday, January 11, 2012 - link

    Why does clockspeed matter? People should stop focusing on the clock so much. The real performance metric is performance per watt. Anyone remember the P4? How about Bulldozer? If intel can get more clockspeed in the same thermal envelope, then good job and they should be able to compare them side by side. I know ARM vendors would clock their chips faster, but then they run into thermal limitations.
  • Wilco1 - Wednesday, January 11, 2012 - link

    For single-threaded benchmarks clockspeed is the only thing that matters. I agree performance per watt is far more important in the real world. This is why dual or quad cores give better performance per watt than a single high clocked core. I don't believe ARM cores are thermally limited, Tegra 3 has 4 cores at 1.3GHz, and even faster SoCs are coming soon.
  • milli - Thursday, January 12, 2012 - link

    "For single-threaded benchmarks clockspeed is the only thing that matters"

    Ever heard of issue-width or instruction re-ordering? Ever heard of MIPS/Mhz? If you have, how can you say such a thing?
  • Wilco1 - Thursday, January 12, 2012 - link

    IPC matters of course but only at similar frequencies. And frequency differences are typically much larger than IPC differences. For example 2-way out-of-order execution gives around 25% better IPC than 2-way in-order, however the frequency difference in the article is 33-60%. So given a large enough difference in frequency, you would expect an in-order to beat out-of-order.
  • milli - Thursday, January 12, 2012 - link

    You can't just paste performance numbers on a cpu based on it's high level architecture. Your example might be right for cpu A & B but you can't apply it just to every cpu.
    Next you'll tell me that a Cortex A15 is as fast clock for clock as a Phenom just because they are both 3-wide OoO architectures? Rest assured that a K10.5 core will be more than double as fast as an A15 (and i'm sure, up to 5-6x faster).
  • french toast - Thursday, January 12, 2012 - link

    I can tell you now that cortex a15 wont be a million miles off clock for clock,even if it doesn't beat it.

    Obviously cache sizes/latency as well as bandwidth will play a part, but cortex a15 will be competitive with phenom, on a tiny fraction of the die space and power consumption.

    cortex-a9 is nearly on par with a ULV core 2 duo clock for clock as difficult as that seems.
  • milli - Thursday, January 12, 2012 - link

    Oh french toast, I've seen your comments here before. You just crack me up. Such a fanboi. I didn't even know there was such a thing as an ARM fanboi but you prove me wrong.
    FYI, an ULV C2D is around 3 to 10x faster than an A9 (clock for clock) and an A15 will get nowhere near a Phenom. Sorry to burst your bubble.
  • kaiyao - Wednesday, January 11, 2012 - link

    While this chip for phones is finally out, does anyone know if Intel going to release any tablet chips anytime soon? Perhaps a dual/quad core version of this chip?

    Because Intel should really push out a chip competitive with ARM when Windows 8 comes out. I imagine if the chip performs as well as an ARM (in terms of performance and power efficiency), and if Intel matches the pricing of ARM chips, Windows 8 tablet manufacturers would definitely choose x86 over ARM to advertise compatibility with legacy applications.

    I remember that the previous "mobile chip" from Intel did not work with Windows 7 due to something along the lines of the lack of PCI bus support, but since Microsoft can port Windows 8 to ARM, clearly this PCI bus is not an issue (if Microsoft modifies Win8 a bit). I presume application code will not be affected by the presence of the PCI bus.
  • guilmon19 - Wednesday, January 11, 2012 - link

    I read somewhere, sorry i don't have a link, that intel was going to release a dual core version by the final quarter
  • Mumrik - Wednesday, January 11, 2012 - link

    Page 4: "and I wouldn't be surprised if more aren't on the way."

    Isn't that the opposite of what you meant Anand?

Log in

Don't have an account? Sign up now