Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Virtual Machine Brings X86 Linux Apps To ARMv7 Devices

timothy posted about 2 months ago | from the ever-widening-abstraction-layers dept.

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

cancel ×

61 comments

Sorry! There are no comments related to the filter you selected.

Why? (2)

Gothmolly (148874) | about 2 months ago | (#47734947)

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?

Re:Why? (1)

NotInHere (3654617) | about 2 months ago | (#47734969)

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

Re:Why? (4, Insightful)

wierd_w (1375923) | about 2 months ago | (#47735179)

Wine.

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.

Re:Why? (0)

Anonymous Coward | about 2 months ago | (#47735259)

As much as this is nice, i'd like to see a better arm visualization on x86 what little exists is expensive and or shitty

Been done already (4, Informative)

DrYak (748999) | about 2 months ago | (#47735555)

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

Re:Why? (1)

Antique Geekmeister (740220) | about 2 months ago | (#47735717)

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

Re:Why? (1)

binarylarry (1338699) | about 2 months ago | (#47736469)

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

Re:Why? (1)

binarylarry (1338699) | about 2 months ago | (#47736475)

It was so ahead of it's time:

http://research.microsoft.com/... [microsoft.com]

Shakespearian touch interface already included baby.

Re:Why? (1)

flyneye (84093) | about 2 months ago | (#47736069)

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

Re:Why? (0)

Anonymous Coward | about 2 months ago | (#47736801)

Except there is no reason to.

Intel already offers a x86 Android image with a ARM translator. But there's little point in doing this. Few people run Linux Desktops, even less want to run Android.

Re:Why? (0)

Anonymous Coward | about 2 months ago | (#47736137)

+1

Re:Why? (0)

Anonymous Coward | about 2 months ago | (#47736679)

My sentiments exactly. It's a solution looking for a problem IMNHO other than just because we can.

The way I see it, joy I can run x86 programs slowly, or ooo I can re-compile them for ARM and run them a bit faster.

I want to see broadwell SoCs, but what I'd really like to see is everyone move on up to 64b and give us more RAM.

Why? (2)

WaffleMonster (969671) | about 2 months ago | (#47734949)

How hard is it to cross compile an application?

Re:Why? (4, Funny)

0123456 (636235) | about 2 months ago | (#47734963)

Pretty hard if you don't have the source.

Re:Why? (1, Flamebait)

fnj (64210) | about 2 months ago | (#47735115)

For what linux application is the source not trivial to obtain?

Re:Why? (0)

Anonymous Coward | about 2 months ago | (#47735495)

For what linux application is the source not trivial to obtain?

Don't forget, you often must have the EXACT same environment etc etc in order to compile source. Plus cross-compiling for another platform isn't always easy depending on the source.

Re:Why? (1)

Anonymous Coward | about 2 months ago | (#47735505)

Oracle Database? DB2? Any commercial application?

Re:Why? (1)

Anonymous Coward | about 2 months ago | (#47735751)

Run on an emulator? Are ya daft, man?

Windows applications, etc. (2)

DrYak (748999) | about 2 months ago | (#47735561)

- For the closed-source windows application that you are running on your open-source wine. (This kind of emulator can bring executing Windows x86 software on your ARM chromebook. Except TFA's emulator is much faster a this than qemu-user-mode).
- For some shitty closed source stuff that you are forced to use (weird proprietary SSL VPN, Microsoft Skype, Adobe Flash, etc.)

Rated garbage (1)

tepples (727027) | about 2 months ago | (#47736125)

For the closed-source windows application that you are running on your open-source wine.

Not when the majority of desirable applications are rated garbage, as another comment points out [slashdot.org] .

Re:Why? (0)

Anonymous Coward | about 2 months ago | (#47735731)

PowerCAD, PowerPCB, AutoCAD, Flash, MPEG players (due to patent issues in the US), DVD players (due to silly ass DVD encryption legal problems for the libdvdcss library.)

Even Java remains a mess to automate installation for. I'm glad Oracle and Red Hat are collaborating on OpenJDI, it's making my life easier.

Games (1)

tepples (727027) | about 2 months ago | (#47736117)

Most games available in the Linux section of Steam are proprietary software.

Re: Why? (1)

LocutusOfBorg1 (1549493) | about 2 months ago | (#47740635)

Dropbox. There is *no* arm version.

Re:Why? (1)

Pinhedd (1661735) | about 2 months ago | (#47735003)

damn near impossible if the source code is not available or has been lost

Re:Why? (0)

fnj (64210) | about 2 months ago | (#47735113)

And the source code to what linux app is "not available" or "lost"?

Re:Why? (4, Insightful)

bloodhawk (813939) | about 2 months ago | (#47735137)

I have plenty where I work where the source code has been lost or has been poorly maintained so that the binary version is significantly different to our only source code copy.

Not all apps are free (1)

tepples (727027) | about 2 months ago | (#47736143)

Not all applications are available from their respective publishers under a free software license. Did you want me to give names of particular proprietary applications for Linux?

Re:Why? (2)

armanox (826486) | about 2 months ago | (#47736407)

Plenty. Matlab, Maya, Documentum, Cisco VPN client, shall I continue? There is plenty of closed, commercial software for Linux.

Re:Why? (0)

Anonymous Coward | about 2 months ago | (#47735169)

How hard is it the translate x86?

Like most things... it's not hard to do... it's just hard to do it well.

Why? (0)

Darinbob (1142669) | about 2 months ago | (#47738235)

So theoretically, if someone finds a Windows program that's worth running, this could be useful?

Re:Why? (0)

Anonymous Coward | about 2 months ago | (#47745705)

not really hard i think if you know how to ^^ http://www.vapbulous.com

Same people as...? (0)

Anonymous Coward | about 2 months ago | (#47735131)

I wonder if they are some of the same people as these (reading about theiur team it does not sound unlikely): http://www.embedded.com/electronics-news/4397737/X86-emulation-coming-to-ARM-processors

Re:Same people as...? (4, Interesting)

Guy Harris (3803) | about 2 months ago | (#47735207)

I wonder if they are some of the same people as these (reading about theiur team it does not sound unlikely): http://www.embedded.com/electronics-news/4397737/X86-emulation-coming-to-ARM-processors [embedded.com]

Well, that link speaks of people from Elbrus, and this page from Eltechs' web site [eltechs.com] says "The MCST Binary Translation Team has 200+ man-year experience in developing binary translators. They implemented a number of x86 to e2k (a Russian CPU)". The "e2k" is probably the Elbrus 2000 [wikipedia.org] , for which they implemented an x86-to-native binary translator. The MCST [wikipedia.org] (Moscow Center of SPARC Technologies) referred to by the Elbrus 2000 page is probably the same MCST referred to by the Eltechs page.

So, yes, probably the same people.

Re: Same people as...? (0)

Anonymous Coward | about 2 months ago | (#47736115)

If this works well they will be bought out by IBM and then not do anything else. (Like Transistive was) .

Windows RT (1)

nateman1352 (971364) | about 2 months ago | (#47735265)

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 (3, Insightful)

nateman1352 (971364) | about 2 months ago | (#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.

Re:Windows RT (1)

Anonymous Coward | about 2 months ago | (#47735487)

I don't think they can hear you.

The standard 30 percent commission (1)

tepples (727027) | about 2 months ago | (#47736185)

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.

Re:Windows RT (1)

jedidiah (1196) | about 2 months ago | (#47736727)

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.

not as versatile as QEMU, but emu performance now (0)

Anonymous Coward | about 2 months ago | (#47735347)

QEMU does the same and much more, however it cannot make use of multicore, therefore it is not difficult to beat in performance. This is starting to hurt more and more and I am not surprised that alternative solutions are being developed.

still slow (2)

throwaway18 (521472) | about 2 months ago | (#47735459)

4.5 times faster than QEMU is still very slow

Re:still slow (4, Interesting)

Lennie (16154) | about 2 months ago | (#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. :-)

Re:still slow (1)

solus1232 (958622) | about 2 months ago | (#47738389)

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 that do any kind of runtime code generation themselves because they would be generating x86 (not ARM) instructions on the fly.

I'm somewhat sad that no one ships LLVM byte code binaries that are lowered to the native ISA at install time. It was one of the original design goals of LLVM, and it would have eliminated all of these issues.

Re:still slow (1)

Wizarth (785742) | about 2 months ago | (#47740661)

It's still the goal of PNaCl variant of Native Client ( https://developer.chrome.com/n... [chrome.com] ). But I haven't heard of anyone actually using this.

Re:still slow (1)

Lennie (16154) | about 2 months ago | (#47740997)

No, dynamically is definitely the wrong approach. It just won't work.

Shippping LLVM byte code could still be possible yes.

Does any distribution have some kind of package that can be installed ? llvm-runtime. Like you can install Python or Java.

Shouldn't be to hard to make a package for Linux for that, right ?

Maybe someone could even add it to the kernel so it can recognise the bytecode.

LLVM for dynamic code generation (1)

Sits (117492) | about 2 months ago | (#47746381)

My understanding is that Apple have done the work to make it viable to use LLVM for certain levels of Javascript JITing [webkit.org] so it is now feasible to use LLVM to compile long running dynamic code. Said code needs to be long running to a) build up information about the instructions being run b) offset the overhead of compilation.

Aaand...obsolete. (3, Interesting)

Anonymous Coward | about 2 months ago | (#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?

Not free? (0)

Anonymous Coward | about 2 months ago | (#47735679)

Meh. I don't care.

Re:Not free? (0)

Anonymous Coward | about 2 months ago | (#47735961)

> Meh. I don't care.

Ditto. I'm all in favor of people making money from software, but this seems like exactly the kind of utility that F/OSS is best at.

Open source it, (0)

Anonymous Coward | about 2 months ago | (#47735701)

assholes.

Re: (1)

kurkosdr (2378710) | about 2 months ago | (#47735939)

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

Re: (1)

kurkosdr (2378710) | about 2 months ago | (#47735941)

different = difference

Re: (1)

Bing Tsher E (943915) | about 2 months ago | (#47736273)

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 general public, and the Pi gives everyone a stable starting point.

wake me when I can run MacOS on OSX (1)

jsepeta (412566) | about 2 months ago | (#47736215)

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

Re:wake me when I can run MacOS on OSX (1)

armanox (826486) | about 2 months ago | (#47736435)

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.

Re:wake me when I can run MacOS on OSX (1)

NormalVisual (565491) | about 2 months ago | (#47736823)

Or you could run SheepShaver [cebix.net] , as long as you don't mind being limited to System 9.0.4 or earlier.

Re:wake me when I can run MacOS on OSX (0)

Anonymous Coward | about 2 months ago | (#47741685)

And as long as you don't mind it crashing constantly. SheepShaver is one of the most finicky pieces of software I've ever used. The slightest weirdness in configuration or unusual app behavior sends it over the cliff. Plus, it's no longer being maintained except by the community.

It's a bit piece of work in concept, but practically speaking it's useless. Or at least that's how it was earlier this year when I gave up on it.

1988 or there about calls back (1)

John Bokma (834313) | about 2 months ago | (#47737489)

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.

Re:1988 or there about calls back (0)

Anonymous Coward | about 2 months ago | (#47737537)

It was nowhere near native speed - ballpark 20-50x slower than an 8MHz 8086.

Emulation Everywhere (1)

pubwvj (1045960) | about 2 months ago | (#47738475)

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 hardware running to use our old applications to access our long term data. That means we don't buy new hardware and that is a short sighted mentality of the hardware makers like Apple, HP, etc. If they made new hardware that would run all past stuff I'd upgrade my hardware in a heart beat putting money in their pockets.

Re:Emulation Everywhere (1)

Gothmolly (148874) | about 2 months ago | (#47745151)

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?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?