www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
HP, Asus announce first Windows 10 ARM PCs
By Thom Holwerda on 2017-12-05 20:19:56

HP and Asus have announced the first Windows 10 PCs running on ARM - Snapdragon 835 - and they're boasting about instant-on, 22 hour battery life, and gigabit LTE. These machines run full Windows 10 - so not some crippled Windows RT nonsense - and support 32bit x86 applications. Microsoft hasn't unveiled a whole lot just yet about their x86-on-ARM emulation, but Ars did compile some information:

The emulator runs in a just-in-time basis, converting blocks of x86 code to equivalent blocks of ARM code. This conversion is cached both in memory (so each given part of a program only has to be translated once per run) and on disk (so subsequent uses of the program should be faster, as they can skip the translation). Moreover, system libraries - the various DLLs that applications load to make use of operating system feature - are all native ARM code, including the libraries loaded by x86 programs. Calling them "Compiled Hybrid Portable Executables" (or "chippie" for short), these libraries are ARM native code, compiled in such a way as to let them respond to x86 function calls.

While processor-intensive applications are liable to suffer a significant performance hit from this emulation - Photoshop will work in the emulator, but it won't be very fast - applications that spend a substantial amount of time waiting around for the user - such as Word - should perform with adequate performance. As one might expect, this emulation isn't available in the kernel, so x86 device drivers won't work on these systems. It's also exclusively 32-bit; software that's available only in a 64-bit x86 version won't be compatible.

I'm very curious about the eventual performance figures for this emulation, since the idea of running my garbage Win32 translation management software on a fast, energy-efficient laptop and external monitor seem quite appealing to me.

 Email a friend - Printer friendly - Related stories
.
Post a new comment
Read Comments: 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-59
.
RE[6]: Garbage in, garbage out.
By Brendan on 2017-12-07 21:19:08
Hi,

> I do commend you for this answer, but such trickery, haha :)

There's no trickery.

> Java programs aren't really emulated in modern JVMs, instead they are run natively with bits and bobs to perform the JIT compilation on the fly. The .class files are merely a binary representation of the source and not an executable binary in the same sense as x86 or arm code.

This doesn't even make sense. Java byte-code is machine code for a "pretend CPU" (ignoring the "Jazelle DBX" extension ARM tried) and as far as JIT is concerned it makes very little difference how real the original CPU was.

All JIT compilers have "bits and bobs to perform the JIT compilation on the fly" - that's literally what JIT is.

> It would be conceptually very similar to take a .c program, zipping it up into a "binary" .c.gz file. And then passing this binary file to a "C-virtual machine" (which achieves 100% of native btw). But the CVM is NOT emulating C, neither is the java virtual machine emulating java(*)... both are compiling it down to native in order to run on bare metal.

Nonsense. Java's compiler compiles Java source code (text) into Java byte-code (machine code for a virtual machine). This machine code is then emulated (with a combination of interpretation and JIT).

> * I am aware the original JVM implementations really did have virtual machine emulation, but this was very slow and not the kind of emulation that achieves "around 90% of native".

The original JVM implementations used "pure interpretation" to emulate the virtual machine (which is slow), and newer JVM implementations use a combination of interpretation and JIT to emulate the virtual machine (which is faster). The use of JIT to emulate a virtual machine does not mean that there is no virtual machine.

Notes: For JIT compiling it costs a little overhead to do the initial translation (and optimising the result costs more), so for code that is only executed once it's faster to interpret. Most emulators that use JIT actually use multiple tiers - interpret the first time it's executed, then do a simple JIT if it's executed more than once, then do complex/optimising (more expensive) JIT if it's executed a lot. If Microsoft are caching the resulting translated code on disk, then they could just do complex/optimising (more expensive) JIT (making it much slower the first time an executable is executed, but significantly faster after that when everything is translated and optimised and there's no more "JIT overhead").

> I think most of the interest in pursuing software emulation was lost with hardware virtualization, but if ARM PCs become more popular, it could stimulate R&D for software emulation again.

Hardware virtualisation only works when the hardware/CPU supports the instruction set being emulated; and CPUs that support hardware virtualisation of other CPUs is almost non-existent (the "Jazelle DBX" extension ARM tried is the only case I can think of at the moment). Modern Intel and AMD CPUs have hardware virtualisation that is only capable of virtualising 80x86 and nothing else. Some modern ARM CPUs have hardware virtualisation that is only capable of virtualising ARM and nothing else.

Most of the interest in cross-architecture software virtualisation comes from economics/marketing - Apple trying to make it possible for existing customers to switch from Motorola 68K CPUs to the completely different PowerPC CPUs; or Apple trying to make it possible for existing customers to switch from PowerPC CPUs to the completely different 80x86 CPUs; or Intel trying to make it possible for existing customers to switch from 80x86 CPUs to the completely different Itanium CPUs.

In other words; it's a solution to the "nobody writes software because there's no users, but there's no users because nobody wrote software" problem.

The other use of virtualisation is "containerisation" (e.g. for security purposes or for "hardware as a service"), and that's where hardware virtualisation is used.

- Brendan
Permalink - Score: 3
.
RE[3]: This is awesome
By CaptainN- on 2017-12-08 00:58:17
Without identifying which part is not correct, your reply is all noise, and no signal
Permalink - Score: 0
.
RE[7]: Garbage in, garbage out.
By Alfman on 2017-12-08 02:02:37
Brendan,

> This doesn't even make sense. Java byte-code is machine code for a "pretend CPU" (ignoring the "Jazelle DBX" extension ARM tried) and as far as JIT is concerned it makes very little difference how real the original CPU was.
...
Nonsense. Java's compiler compiles Java source code (text) into Java byte-code (machine code for a virtual machine). This machine code is then emulated (with a combination of interpretation and JIT).
...
The original JVM implementations used "pure interpretation" to emulate the virtual machine (which is slow), and newer JVM implementations use a combination of interpretation and JIT to emulate the virtual machine (which is faster). The use of JIT to emulate a virtual machine does not mean that there is no virtual machine.


The java byte code is merely a binary representation of the source code. The binary format makes it easier for computers to parse, but it is equivalent to the source code (minus comments and whitespacing). It's not very accurate to say that the JVM translates from one machine code to another in the same sense as x86 to ARM does.

Look, I don't want to argue over semantics, so if you want to view it as a virtual machine, then fine. But make no mistake, putting a "virtual machine" label on a java compiler does NOT put it in the same category as x86 machine code virtualization. The Java compiler's binary input is equivalent to the original source. On the x86 side we simply don't have the source code in any format to recompile natively to another platform. This is why equating the two is trickery. I'm still glad you brought it up, but the JVM performance numbers aren't necessarily meaningful for x86 machine translation.


> Hardware virtualisation only works when the hardware/CPU supports the instruction set being emulated; and CPUs that support hardware virtualisation of other CPUs is almost non-existent (the "Jazelle DBX" extension ARM tried is the only case I can think of at the moment). Modern Intel and AMD CPUs have hardware virtualisation that is only capable of virtualising 80x86 and nothing else. Some modern ARM CPUs have hardware virtualisation that is only capable of virtualising ARM and nothing else.

Yes, the rise of ARM PCs may help push cross architecture software emulation further. I use hardware virtualization all the time for my servers, but it's not so clear whether I'd have a need to do cross-platform virtualization.

I may one day have ARM servers, but it's hard to envision a scenario where I'd be running an x86 VM on an ARM server or an ARM VM on an x86 server. The goal of virtualization is usually to do it with minimal performance overhead, hardware virtualization gets us there but without a lot more progress software virtualization probably does not. I'd still play with it though :)
Permalink - Score: 3
.
RE[4]: This is awesome
By Kochise on 2017-12-08 05:56:10
You are true, it can't run Itanium compiled applications so it is a crippled version of Windows.
Permalink - Score: 2
.
...I don't really like Windows 10 enough to want to buy
By dionicio on 2017-12-08 19:49:10
Will wait for Acer, from S frame, for a start.
Permalink - Score: 2
.
RE[8]: Garbage in, garbage out.
By Brendan on 2017-12-09 06:43:15
Hi,

> The java byte code is merely a binary representation of the source code. The binary format makes it easier for computers to parse, but it is equivalent to the source code (minus comments and whitespacing). It's not very accurate to say that the JVM translates from one machine code to another in the same sense as x86 to ARM does.

Would you at least do some basic research (e.g. check the wikipedia page - https://en.wikipedia.org/wiki/Jav... ) before you embarrass yourself further?

> Yes, the rise of ARM PCs may help push cross architecture software emulation further. I use hardware virtualization all the time for my servers, but it's not so clear whether I'd have a need to do cross-platform virtualization.

To add same architecture virtualisation you mostly only need to do something with memory management ("nested paging") and trap special/system instructions (and maybe add an IOMMU if you like). 99% of the CPU (including all normal instructions, stack, etc) remain the same.

To add cross architecture virtualisation (assuming legalities and marketing don't forbid it) you need all of the stuff that's needed for same architecture virtualisation plus all of the normal instructions (it's no longer a case of "99% of the CPU remains the same" and becomes "add a whole new instruction decoder"). Then you get to the nasty stuff (e.g. incompatible memory ordering) where you have to modify cache coherency protocols and everything (and not just the CPU). Then you get the cost of validating all of it to (try to) make sure it all behaves like it should (which is already an extremely arduous and expensive task). By the time you're finished with all of this, a "$400 consumer CPU" doubles in price, and you go bankrupt because nobody wants to pay twice as much.

Mostly; it's never going to happen (even if legalities and marketing don't forbid it).

Of course legalities do forbid it. You can't implement the ARM instruction set without entering into a licencing agreement with ARM (and paying licencing fees, etc), and you can't implement the 80x86 instruction set without patent agreements with both Intel and AMD; and none of these companies have any reason to welcome unwanted competition. Intel has already threatened Microsoft/Qualcomm with patent infringement lawsuits and they're just doing software emulation. This is likely to also be the reason why Microsoft's emulator only supports old 32-bit 80x86 code (they probably can't emulate modern 64-bit 80x86 because of Intel's patents, although I suspect that's more to do with SSE/AVX than 64-bit itself).

- Brendan
Permalink - Score: 2
.
RE[9]: Garbage in, garbage out.
By zima on 2017-12-09 14:55:34
Don't Loongsoon CPUs have partially hardware-assisted x86 virtualisation? And it didn't seem todouble their price... Of course, they don't care much about legalities.
Permalink - Score: 2
.
RE[9]: Garbage in, garbage out.
By Alfman on 2017-12-09 20:32:36
Brendan,

> Would you at least do some basic research (e.g. check the wikipedia page - https://en.wikipedia.org/wiki/Jav... ) before you embarrass yourself further?

With all due respect you are focusing on something I already know while you are missing the crux of why it doesn't matter. Yes the class files are in a format that was originally used for emulation. But regardless for the purposes of the JIT compiler, inputting a binary class file is effectively the same as inputting the original java source code because you can go back and forth between java source and byte code over and over again without losing the original semantics or adding new side effects. It's by and large a lossless process.

You don't even have to take my word for any of this, go see for yourself what it's like to decompile and recompile java. Then try to do the same for x86 machine code. Once you've experienced this you'll see why my point is quite valid. x86 machine code does not map to the high level objects and constructs in a 1:1 fashion the way it does in java. This means that even though the JIT compiler is inputting binary code, it is practically the same as if it had been source code.

In particular as it relates to our discussion, using java bytecode as input for the JIT compiler does not incur any performance overhead over using the java source code. I know that in the end you'll come to agree with me on this point :)
Permalink - Score: 2
.
RE[3]: Comment by smashIt
By klahjn on 2017-12-10 03:15:18
I used to HATE supporting the Transmeta Crusoe, despite liking the idea (in theory).

Brings me back to the late 90's-2001 when I worked for Sony... crazy times... I remember coming into work and wondering why flag was at half mast, until they told me about the towers...

::shakes off rambling:::

damn nostalgia!! lol
Permalink - Score: 1

Read Comments 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-59

Post a new comment
Username

Password

Title

Your comment

If you do not have an account, please use a desktop browser to create one.
LEAVE SPACES around URLs to autoparse. No more than 8,000 characters are allowed. The only HTML/UBB tags allowed are bold & italics.
Submission of a comment on OSNews implies that you have acknowledged and fully agreed with THESE TERMS.
.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?