Russian team develops x86 emulator on ARM | Hacker News Reader

Russian team develops x86 emulator on ARM

cdn.eetimes.com

50 pointsadityar33 comments

Doesn't qemu already do this? Is the Russian's code faster?

I believe qemu's userspace mode doesn't work on an ARM host.

It does, assuming your ARM host is at least ARMv6 or v7 (v5 doesn't deal with unaligned accesses and QEMU userspace mode doesn't do anything special with guest binary unaligned accesses, so they appear as host unaligned accesses).

QEMU's i386 userspace mode emulation is a bigger problem -- most notably it doesn't handle multithreaded guest binaries (to an even bigger extent than QEMU's general issues with multithreaded guest binaries).

None of these are insurmountable problems; it's just that nobody so far has cared enough about them to put in the time to develop fixes and get them through code review on the mailing list. Patches welcome :-)

QEMU is regularly being used in the Emulator scene as a host for x86 binaries, mostly DOS stuff, though. Its a decent enough 8086 emulator, 386'ish too ..

It wouldn't be a shock if the Russians' code was based on QEMU.

I would be mildly shocked if it was, because (a) the relevant bits of QEMU are under GPL or LGPL, and it doesn't seem very likely that you could get $1.3m investment for a product you'd have to GPL, and (b) if you're interested purely in userspace application translation (and especially if you are happy to restrict to a single guest and single host architecture) then you can almost certainly come up with a better-suited design for that than QEMU (which is rather generalised and focused more on system emulation than userspace).

Is this the same group that worked on the Elbrus VLIW computers? http://en.wikipedia.org/wiki/Elbrus_%28computer%29

Yes they are the same

They have already implemented a software dynamic binary translation virtual machine, similar to Transmeta Crusoe With real hardware booting window/linux

http://en.wikipedia.org/wiki/Elbrus_2000

I guess is that binary translation virtual machine could be tweaked for ARM instruction set

An x86 emulator optimized for ARM:

  http://www.aemula.net

So this is a purely software solution? I wonder if we could see ARM SoCs with some hardware for decoding x86 instructions and have them executed by the ARM core.

After all since ARM7 most ARM cores support both ARM and THUMB instruction sets.

I'm not sure you could do that without permission from Intel though.

According to Wikipedia, the instruction set is open, but for "some advanced features," they may need a license from Intel. I'm not sure what advanced features that would be.

Probably things like SSE.

Indeed, AMD licenses the SSE from Intel, and Intel licenses x64 from AMD.

At that point, it'd basically become an x86 core, with all the space and complexity that requires.

It's easier to translate in software.

I was not thinking about full blown x86 support, but partial support where it matters. A bit like the Jazelle Java bytecode support, it wouldn't really run x86 code in native but would support extensions that would make it easier and faster. I'm not familiar enough with the x86 instruction set to guess where this would really improve performances though.

Even Jazelle is being dumped, since it was too complex in hardware. And x86 is much more complicated than JVM bytecode.

Modern "Jazelle" is basically just Thumb (I think it's even called Thumb EE), and it requires software to translate to it (JIT to Thumb instead of to ARM).

> I'm not sure you could do that without permission from Intel though.

Then how does AMD do it?

AMD licenses the right to produce x86 compatible chips from Intel.

That's because AMD cores were not independently developed from scratch.

Cyrix core, on the other hand, was. They never oficially licensed x86 and the problems between Intel and Cyrix ended as out of court settlement to save Intel's face.

I don't think decode is really the hard part; if you're JITting at all it's pretty easy. The difficulties arise where the semantics of the target and the host don't match up. For instance, emulating a strong-memory-model architecture like x86 on a weak-memory-model architecture like ARM requires a pile of explicit memory barriers if you're going to handle multi-threaded binaries. Emulating atomic memory accesses might also be tricky. Differences in floating point semantics (like x86's 80-bit format or just different choices of IEEE implementation specifics) are also painful: QEMU takes the slow-but-safe option of doing all the floating point emulation in software (ie using integer arithmetic) to ensure bit-for-bit accuracy. None of these pain points is really related to the instruction decoding.

According to Herb Sutter at [1], ARMv8 will support a couple new ops to support sequentially consistent memory access.

1: http://herbsutter.com/2012/08/02/strong-and-weak-hardware-me...

What server applications that matter cannot be recompiled for ARM but will work effectively under emulation?

Anything with a JIT compiler? For example, the status of Java on ARM is getting better, but still rumoured to not be as fast as on x86.

And anything that is not open source? Proprietary software is still used heavily on servers running an open source stack. Having a performant emulation or translation option could help with odd pieces that vendors haven't recompiled. Although support would be an issue for this at enterprise level.

Rumored? Are there numbers somewhere or is it still in development or something?

>Anything with a JIT compiler? For example, the status of Java on ARM is getting better, but still rumoured to not be as fast as on x86.

If performance is the worry I highly doubt running through an x86 emulator is going to be faster.

Within a few years, Intel CPUs are soon going to compete with ARM.

We've been hearing that for the past few years.

They already compete. More and more markets will be affected over time.

To run VMWare->Windows->JVM->Scala/Closure "state of the art" stuff, I suppose..

What is the state of the JVM on ARM, can you run enterprise stuff on top of Dalvik?

I don't think the state of enterprise JVM support on ARM is a reason run x86 JVM under software emulation on ARM.

Intel would eat that idea for breakfast.

There are real JVMs on ARM, plus Jazelle Java acceleration.

Cortex A15 and beyond will support hardware virtualization.

Dalvik is not a JVM implememtation. But there is JVM for ARM. It is slow and much less optimised. Most enterprise java stuff is going to need more memory than you get on ARM.

Reply on news.ycombinator.com