Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Android Emulation (Games) Intel Software Linux Hardware Technology

Virtual Machine Brings X86 Linux Apps To ARMv7 Devices 61

DeviceGuru writes Eltechs announced a virtual machine that runs 32-bit x86 Linux applications on ARMv7 hardware. The ExaGear VM implements a virtual x86 Linux container on ARMv7 computers and is claimed to be 4.5 times faster than QEMU, according to Eltechs. The VM is based on binary translation technology and requires ARMv7, which means it should run on mini-PCs and SBCs based on Cortex-A8, A7, A9, and A15 processors — but sadly, it won't run on the ARM11 (ARMv6) SoC found on the Raspberry Pi. It also does not support applications that require kernel modules. It currently requires Ubuntu (v12.04 or higher), but will soon support another, unnamed Linux distro, according to Eltechs, which is now accepting half price pre-orders without payment obligation.
This discussion has been archived. No new comments can be posted.

Virtual Machine Brings X86 Linux Apps To ARMv7 Devices

Comments Filter:
  • Other than a desire to run the x86 version of Doom on your BeagleBoard, why would you need this when software is just a recompile away?

    • ... and Linux didn't regard binary compatibility (I actually like that), so that you always need to have the source around?

    • Re:Why? (Score:5, Insightful)

      by wierd_w ( 1375923 ) on Saturday August 23, 2014 @01:37AM (#47735179)


      This allows wine to run on exotic hardware. (Well, at least ARMv7)

      This means that theoretically, tablet-flavor windows applications can be run on linux derived tablet OSes with wine libraries, and other fun things.

      You should not be so cynical about something like this. It's a feature that's been missing from the landscape for some time now.

      • Been done already (Score:5, Informative)

        by DrYak ( 748999 ) on Saturday August 23, 2014 @07:04AM (#47735555) Homepage

        qemu-user-mode + wine has been done for some time already. It more or less works for Windows x86 executables on ARM Linux.
        (In fact, the first user-mode emulators where designed to help run x86 code back when Apple used PPC).

        The novelty of TFA's emulator is its claimed performance.
        That's the interesting stuff. Doing translation (like some emulators running on x86 host do) is going to take a lot less CPU than emulating a complete CPU in software (as qemu currently does on ARM host). Which means longer battery life, which is a big advantage in some markets (tablets and smartphone).

      • > This allows wine to run on exotic hardware. (Well, at least ARMv7)

        Except that it doesn't. Do check the compatibility ratings at https://appdb.winehq.org/ [winehq.org], and select for the word "garbage". Sadly enough, even the compatibility site itself is quite horrible. Like maintaining Wine itself, it requires manual drilling down into individual components to get any useful information about them.

      • Huzzah, finally I'll be able to run Office 97 on my Android Phone.

    • by flyneye ( 84093 )

      I'm thinking that running Android apps on Linux would be the more cost effective solution.

  • by WaffleMonster ( 969671 ) on Saturday August 23, 2014 @12:14AM (#47734949)

    How hard is it to cross compile an application?

  • This would be a much more interesting technology for Windows RT as it would make those devices actually semi useful if the Windows back catalog was available on them.

    • Re:Windows RT (Score:4, Insightful)

      by nateman1352 ( 971364 ) on Saturday August 23, 2014 @03:04AM (#47735273)

      ...That said Microsoft would have to get the clue that developers have zero interest in Metro/Modern/Whatever apps, the environment is so limited that porting a Win32 app is basically as much work as porting a Win32 app to Android (esp. with stuff like Xarmarin, Qt, and other great cross platform libraries available to help) and nobody wants to pay MS 30% of their revenue and limit their distribution channel so strictly.

      Sorry Microsoft management, I know leveraging market position in your core product line to push yourself in to a new market is one of the oldest tricks in your book. In this case, its trying to use regular Windows to push developers in to building software that is compatible with WinPhone so you have the catalog of 3rd party software needed to make WinPhone successful. Thing is in order for it to work this time Windows on tablets would need to be the universally preferred tablet OS. 10 years ago legacy Win32 compatibility would have been all you needed to be the preferred tablet OS, but since you gave the competition 3-4 years to build up a nice back-catalog of touch friendly 3rd party software Windows is NOT the preferred tablet OS, Android and iOS are.

      You have nobody to blame except yourselves for giving your competitors that much time (well, maybe your former now retired CEO.) At this point just take a page from your buddies over at Intel, they made it so installing any arbitrary .apk on a x86 Android device just works (even if it has ARM native code.) And look, consumers are buying x86 Android tablets without a second thought since everything just works, hell a lot of the time an x86 Android tablet isn't even labelled Intel vs. ARM its so seamless. Make it so you can install Android .apks on Win8/RT/Phone, that will give you access to the software catalog you need to break in to the market. It would be even better if you could work about a deal to get Google Play on Windows... but I doubt Google will want to "play" with you at all :) The preferred route of making everyone else bend and do things your way its pretty much a non-starter at this point because you waited so long.

      • by Anonymous Coward
        I don't think they can hear you.
      • nobody wants to pay MS 30% of their revenue

        Them explain applications in PlayStation Store, Xbox Live Marketplace, Nintendo's eShop, Apple's App Store, Amazon Appstore, Google Play Store, Steam, etc. Sometimes a 30% cut can be can be easier than buying SSL hosting, a merchant account, and store tech support staff, especially with the swipe fees that card processors charge for small purchases and the $5 setup fees that stores charge for MC/Visa/AMEX gift cards.

    • by jedidiah ( 1196 )

      It would be simpler easier and faster just to have an older x86 core around to run the Intel binaries. It would be like any number of "emulation" boards that existed for DOS back in the 80s and 90s.

      This is insane. You are trying to emulate a faster system with a SLOWER system.

      This can only end in pain and anguish.

  • by throwaway18 ( 521472 ) on Saturday August 23, 2014 @06:19AM (#47735459) Journal

    4.5 times faster than QEMU is still very slow

    • Re:still slow (Score:5, Interesting)

      by Lennie ( 16154 ) on Saturday August 23, 2014 @08:39AM (#47735791)

      Maybe it is just me but when I see these things, I sometimes get crazy ideas. And I think:

      Might as well translate into LLVM bitcode and recompile the code:
      http://www.phoronix.com/scan.p... [phoronix.com]

      Hell, maybe it's even faster if you compile the LLVM bitcode with emscripten and use asm.js to run into the browser. :-)

      • LLVM is probably too heavy-weight to run dynamically. It generates high quality code, but it isn't designed to compile short traces of instructions like you would need to do in a dynamic binary translator.

        This might not be a bad idea if it could be done once when the binary is installed. However, this is just impossible to do in general for x86 because it isn't always possible to tell the difference between data and code before the program tries to execute it. This is especially true for applications tha

  • Aaand...obsolete. (Score:3, Interesting)

    by Anonymous Coward on Saturday August 23, 2014 @06:41AM (#47735507)

    How about converting the binary directly?

    X86->LLVM IR->anything:
    http://infoscience.epfl.ch/rec... [infoscience.epfl.ch]

    Opensource, too. repository:
    https://dslabgit.epfl.ch/git/s... [dslabgit.epfl.ch]
    (checkout revgen)

    has anyone tried it?

  • And what DOES run on the Raspberyy Pi? The Raspberry Pi requires special binaries, and even then the performance is bad. It was already-obsolete when released, now it's vintage. Just buy an ODROID-U3. For a price different that is essentially pocket change, you get much more utility. And it runs Real Android (tm) with Play Store. I even run Vector Unit's games with no third party app (and Gameloft games with the Tincore Keymapper app).
    • different = difference
    • The Raspberry Pi is designed as a pedagagical, easy-to-access entry point for new programmers to get involved and learn about experimenting and adventuring on computers. It was never about being 'the ideal embedded platform' for slashbots to use for their Media Center computer. Sure it's vintage, but other successful and popular single-board systems are even 8-bitters, like the Arduino, and still very successful and valuable to have out there for people to use.

      Moving targets are not 'friendly' to the gene

  • Seriously, I'd love to run older apps (games) on my Mac Pro. Very little reason for Apple to Kill Rosetta except spite.

    • by armanox ( 826486 )

      You'd need classic mode to do that, which was phased out a lot sooner. Rosetta was for running applications that were compiled for OS X on PPC.

  • Ah, the days that an Acorn Archimedes with an ARM2 running at 8MHz could emulate a 80186 (if I recall correctly) at (near) native speed. It was a very smart move by Acorn: there was a Beeb emulator and a PC emulator.
  • In this day and age of such powerful advanced hardware in our hands they should be offering emulation of all past significant processors including 68K, PPC, x86, etc as well as all previous OSs.

    We have applications for accessing data that we still need to work with. Just because the processors change doesn't mean we can throw away our old data or tools. It is arrogance and greed of the industry that creates this problem. They've are on a disposable mentality.

    The result as it stands is we have to keep older

    • But they don't have to make new hardware that "runs all past stuff" because the other 999,999 people out of a a million will simply buy the new one.

      Whose to blame here?

We all like praise, but a hike in our pay is the best kind of ways.