Microsoft and Qualcomm Collaborate To Bring Windows 10, x86 Emulation To Snapdragon Processors (anandtech.com)

An anonymous reader quotes a report from AnandTech: Today at Microsoft's WinHEC event in Shenzhen, China, the company announced that it's working with Qualcomm to bring the full Windows 10 experience to future devices powered by Snapdragon processors. These new Snapdragon-powered devices should support all things Microsoft, including Microsoft Office, Windows Hello, Windows Pen, and the Edge browser, alongside third-party Universal Windows Platform (UWP) apps and, most interestingly, x86 (32-bit) Win32 apps. They should even be able to play Crysis 2. This announcement fits nicely with Microsoft's "Windows Everywhere" doctrine and should come as no surprise. It's not even the first time we've seen Windows running on ARM processors. Microsoft's failed Windows RT operating system was a modified version of Windows 8 that targeted the ARMv7-A 32-bit architecture. It grew from Microsoft's MinWin effort to make Windows more modular by reorganizing the operating system and cleaning up API dependencies. The major change with today's announcement over Windows RT and UWP is that x86 apps will be able to run on Qualcomm's ARM-based SoCs, along with support for all of the peripherals that are already supported with Windows 10. This alone is a huge change from Windows RT, which would only work with a small subset of peripherals. Microsoft is also focusing on having these devices always connected through cellular, which is something that is not available for many PCs at the moment. Support will be available for eSIM to avoid having to find room in a cramped design to accommodate a physical SIM, and Microsoft is going so far as to call these "cellular PCs" meaning they are expecting broad support for this class of computer, rather than the handful available now with cellular connectivity. The ability to run x86 Win32 apps on ARM will come through emulation, and to demonstrate the performance Microsoft has released a video of an ARM PC running Photoshop.

Comments

Will apples one be app store only or will they do

[Joe_Dragon]

Will apples one be app store only or will they do same and let it run any app?

ARM Server CPUs, x86 on ARM

[HalAtWork]

I feel a transition coming for the low end... Wonder how Intel feels?

Re:ARM Server CPUs, x86 on ARM

[ausekilis]

Intel has seen the writing on the wall for some time now, that's why they've been pushing the Atom and i3 chips to lower and lower power consumption. They need to get some level of parity with the ARM chips or those areas where ARM excels (low power, low heat) will be eating Intel's lunch.

The Intel powered phones weren't quite there in power consumption, but they certainly had processing power. With ARMs becoming more ubiquitous and general-purpose, you can bet your ass Intel is pushing to keep their hardware in use.

Re:ARM Server CPUs, x86 on ARM

[unixisc]

When Intel had XScale, that was DEC's StrongARM, and DEC was noted for high performance, but never low power. The XScale was fine as an embedded CPU but not for low power applications, which is why it went nowhere.

Re:ARM Server CPUs, x86 on ARM

[caseih]

So far in the micro server and embedded space, ARM has been particularly disappointing to me. I have a drawer full of ARM devices I've accumulated over the years. SheevaPlugs, GuruPlugs, RouterStation, etc. All are potentially useful devices, but ARM is hobbled by proprietary boot systems and differing device trees and proprietary supporting hardware. These devices rely on customized linux distributions, and they are often fairly hard to update to new kernels and new flash file systems. Some of these devices have good CPU performance specs, but in practice I've never had them outperform an intel-based server, even a small low-powered one like the atom.

And now in embedded space we have a plethora of Arm-based devices based on lots of different SoCs from companies all over the world. All with their own forks of Linux. We've got Raspbery Pis, Orange PIs, Pine64s, etc. All very interesting and probably useful. But a nightmare to do anything with in a sustainable way.

The Pi (and some of these devices) at least is easy to update since everything comes off of the sd card, with no kernel flashing required. And some of them like the Pi have a fair amount of hacker inertia behind them, so they are capable of doing cool things (maybe not as server replacements though).

With x86-based embedded systems and small servers, at least I can run more standard, off-the-shelf distros on them. I'd far rather deal with a conventional linux server than a sheevaplug, even if the sheevaplug is a nice tiny thing with lots of potential.

In fact my current home office router is a small, low-power Intel-based computer running bog standard, minimal install of CentOS 7. Wifi is hung off of that using a consumer-grade access point running in bridge mode.

If arm devices had a standard boot process like ufi or even the bios, and could boot off of a variety of devices in a standardized way, including ssds, hard drives, usb sticks, and internal flash storage, and could run stock distributions downloaded from distribution web sites, without custom kernels, then I'd say for sure x86's days are numbered. Arm is good at remaining fragmented though.

Re:ARM Server CPUs, x86 on ARM

[PCM2]

When I've heard people talk about "ARM servers," the fine print tends to be that they're not really talking about ARM CPUs, they're talking about ARM SoCs ... so however many ARM CPU cores paired with other components that tailor the SoC for specific workloads. The resulting ARM servers probably won't be general-purpose hardware for everybody to use, they will be marketed to people who know the specific thing they want to do and now they just want to hit the sweet spot on power consumption/cost/whatever.

Re:ARM Server CPUs, x86 on ARM

[Anonymous Coward]

The ARM platform mess is likely one of the reasons behind the rapidly growing support for the RISC-V architecture. The more obvious one being that no one wants to pay rent in perpetuity. ARM may not be as bad as intel, but they are definitely still a substantial burden on hardware developers, and a good open architecture and platform is what just about everyone wants. With Android being mostly platform neutral, I think ARM will also be in for a rude surprise, and turn out to have been a foolish investment for Softbank.

Re:ARM Server CPUs, x86 on ARM

[Big Hairy Ian]

I wonder if they'll transition Windows Server as well https://hardware.slashdot.org/...

Performance?

[crunchy_one]

According to TLA, x86 compatibility is achieved through emulation. Emulating the x86 instruction set is a non-trivial exercise that almost invariably results in extremely disappointing performance. Why? The x86 instruction set is an accretion of the instruction sets of older Intel processors, beginning with the 8008. This yields a difficult (i.e., computationally expensive) instruction set to decode and execute. Over the years, Intel has implemented micro-architectures that address this problem through special purpose hardware. If you're so inclined, have a read here http://www.intel.com/content/w... for details. The takeaway is that simply emulating the x86 instruction set results in about a 100x slowdown for an equivalent clock rate. So, although this is an interesting technology demonstration, I seriously doubt it will prove useful outside of a small set of applications. It will certainly not be a satisfactory gaming platform.

Re:Performance?

[mlw4428]

So you're saying it'll run Crysis?

Re:Performance?

[kronix1986]

"The takeaway is that simply emulating the x86 instruction set results in about a 100x slowdown for an equivalent clock rate. So, although this is an interesting technology demonstration, I seriously doubt it will prove useful outside of a small set of applications. It will certainly not be a satisfactory gaming platform."

Sounds like you didn't read the article or watch the embedded video, where MS show x86 Photoshop and x86 World of Tanks being emulated on Windows 10 ARM and a Snapdragon (835?) SoC - and running fine.

Re:Performance?

[Halo1]

The takeaway is that simply emulating the x86 instruction set results in about a 100x slowdown for an equivalent clock rate.

Emulation definitely results in slowdowns, but it's generally much less than 100x. In particular since any emulator that focuses even slightly on performance uses dynamic compilation: it translates the code once from x86 to the host architecture and from then on runs this translation. The translated version will probably be less efficient than the original code, but by no means 100x slower. 2x to 5x seems more realistic on average, although there are certainly outliers (e.g. code that intensively mucks with system registers or that triggers context switches will be slower, while some straightforward calculation loops may actually become just as fast as or even faster than the original code depending on the target architecture's nature).

Re:Performance?

[ET3D]

I believe press releases (particularly when coupled with demos) a lot more than I believe random people on the internet. That's applying critical thinking.

Re:Performance?

[__aaclcg7560]

So you're saying it'll run Crysis?

The Cyrix processor was a nice low-end processor with great Linux support back in the Socket 7 days. But no one wants to emulate that processor today.

https://en.wikipedia.org/wiki/Cyrix_6x86

Re:Performance?

[GoRK]

Your information is highly dated and perhaps your sources are also a bit biased. At any rate, 100x performance hit is stupid wrong.

Static translation was achieving 50-70% native performance rates (measured against clock cycles) with FX!32 on Windows NT for Alpha in the mid 90's. The problem of course has been very well studied since then particularly with the advent of virtualization and the x64 instruction set and the need to enhance the performance of x86 code running on even Intel's own platforms. Furthermore for any particularly glaring issues that are the fault of the hardware -- well it is much more easily tuned today than it once was. A bespoke opcode or extra register to assist in a specific task is no longer a monumental engineering undertaking today -- it is a matter mostly of dev/test/validate.

The approach taken with x64 to support x86 native execution is quite different than attacking the problem with emulation. Is there a performance hit? Certainly, but a hit of 10-20% simply doesnt make up for the fact that you might be able to have an 8 core ARM for the same price and power budget as a 2 core x86 mobile cpu. The applications that lose in this scenario are the ones the rely on raw single thread performance. Certainly some games are in this camp, but many games which make efficient use of threads are not.

Re:Performance?

[bluefoxlucid]

It depends on if they emulate it by translation and shadowing, or by interpretation. Software translation is rather fast, but not native-fast. To get native-fast, you have to go native.

I've been suggesting an accelerator chip (maybe even off-die) that decodes x86 instructions into the internal RISC instructions stored in the ICache, but people keep telling me it's impossible because... they're stupid. Modern x86, x86-64, and ARM chips all read instructions in their ISA and translate to an internal CPU RISC ISA, to the point that x86-64 chips actually translate x86 instructions to take advantage of around 60 hardware registers thanks to having not just twice as many GPRs (16!), but those GPRs being 64-bits wide (32 GPRs), plus the EBP, ESP, and EIC registers being 64 bits wide and only validly addressing a 32-bit address space (3 more registers). Multiple instructions hitting the same memory won't just work on cache (fast), but will actually load that cache line to register (extremely fast) and operate a series of instructions there--even out-of-order instructions.

No doubt the instruction decoder would be large-ish, and access to its own (I4) cache would prove a performance boon if that cache is kept consistent with actual RAM. Nevertheless, it should be roughly-trivial to produce a CPU chipset that can execute both x86-64 and ARM64 code, in the same way it's roughly-trivial to produce a CPU chipset that executes both x86 and x86-64 or ARM and THUMB. These aren't simple tasks by any means; but the fact is we routinely create chipsets which execute an ISA, and chipsets which execute multiple ISAs, and even chipsets which execute old ISAs while automatically leveraging internal facilities such as registers available to new ISAs (which isn't impressive when you think about OOE, parallel execution, and branch prediction). x86-64 is related to x86, but only at face value; they're different instruction sets, just like ARM and MIPS are different, and it should be fairly easy--not cheap, mind you--to wedge x86-64 in with ARM.

Re: Performance?

[K. S. Kyosuke]

I believe that Dynamo/RIO or how that thing was called actually managed to occasionally produce code *faster* that the original, if said code was generated with an inferior compiler.

Re:Performance?

[drinkypoo]

The applications that lose in this scenario are the ones the rely on raw single thread performance. Certainly some games are in this camp, but many games which make efficient use of threads are not.

It's not that simple. Games are multithreaded now, yes, but they do not have a crapload of threads which can make use of a crapload of cores. If you're taking a substantial clock rate hit and another substantial hit from translation overhead, the truth is that it's not just the high-end games which are going to suffer, nor the low-end ones, but any of them which are not very old — as defined by coming from the era when PCs had even lower clock rates. It's already true that Intel processors with less cores still beat AMD processors in gaming benchmarks, notably in the area of minimum frame rate — the torque of graphics performance, where the max frame rate is horsepower. We all like high max frame rates, but high minimum frame rates are what really matter. (price:performance is also relevant, which is why I went AMD anyway; both CPU and motherboard are cheaper, which translates into a big savings at the system price level. I am not in competition, and I can live with slightly degraded graphics.)

Re: Performance?

[Halo1]

Back then it was still Dynamo. And they only managed to do that on a particular HP PA-RISC architecture, because it was very sensitive to instruction cache missers (or had a bad branch predictor?) so that creating linear traces of code was very performant. They later tried to reproduce it on x86 and failed horribly (just like I did during my master's thesis; the best I got was a 20% slowdown for gzip, I think the best they got was no performance loss with some benchmarks).

Re:Performance?

[chispito]

Don't believe everything you read/see in a press release. Apply some critical thinking.

A reasonable person that both watches the video and reads your comment would conclude that either you are mistaken, or Microsoft and Qualcomm have somewhat overcome or mitigated the issues you point out.

Re:Performance?

[maestroX]

Much less than 100 times alright, but somehow most JITs/emulators (hello Transmeta) manage to incur a ridiculously high load on the system so running multiple large emulated apps simultaneously is troublesome. Why not distribute in CIL or llvm IR format?

Re:Performance?

[Halo1]

Having an intermediate format that you statically translate into the target architecture is definitely useful (like Android is now doing with ART), but keep in mind that LLVM IR is not architecture-independent most of the time. E.g., when LLVM IR is generated from C, then this C code will at least have been compiled based on a certain pointer size, size of long, size of long long, alignments for struct fields, etc. CIL is better in this regard.

However, you should see this as a solution that will be used in an addition to running native apps, not as something you promote to do instead. It probably mainly because it seems unlikely that all, or even many, developers will start shipping tons of Windows 10 AArch64 applications right away. It's a bit like how Apple shipped Rosetta with the first Mac OS X versions for Intel Macs so they could emulate PowerPC apps (and an m68k emulator with the PowerPC versions of classic MacOS), while at the same time encouraging developers to start creating native Intel apps.

Re:Performance?

[im_thatoneguy]

I think it's safe to say it's slower, but as I used to remind the engineers when they pushed back against releasing slow solutions when I was working as a liason between customers and engineering: "not working is infinitely slow".

It's easy to see how Microsoft wants this for the Surface Phone since it will allow customers to run x86 applications on their phone. If your choice is between not running an application and running it slowly, most people will always choose "slowly". Most Win32 software isn't high performance software. And a lot of the really computationally hard stuff is getting moved to GPU anyway. So for instance photoshop has shifted much of its filtering and canvas rendering to OpenCL/CUDA. The Snapdragon should have a perfectly adequate if not superior OpenCL benchmark compared to a low-end intel built in GPU. Same with games. Even if you take a pretty large performance hit on CPU cycles, usually it's the GPU bottlenecking not the CPU. So their magic emulator should natively execute all DirectX/OpenGL calls on the GPU anyway.

The Xbox team has done a great job of this on the Xbox One backwards compatibility for PowerPC RISC support on the Xbox One.

Re: Performance?

[K. S. Kyosuke]

If you could get (say, on ARM) that 20% slowdown for code transpiled from x86 binaries (with a native build being the baseline), I guess you'd be very happy? And so would we. This *could* be useful.

Not all emulation

[Anonymous Coward]

Only the Win32 x86 apps are emulated. The Win64 bit ones are not, and neither is the OS. That is why the performance is good (check the video). Hope that helps.

Re:Not all emulation

[Guspaz]

The Win64 ones aren't emulated because they simply aren't supported.

Re:Not all emulation

[PCM2]

That's not actually that big of a downside. With Microsoft Office, for example, Microsoft still recommends most users install the 32-bit version, even though almost everybody is running a 64-bit OS these days. The exception is people who need to run crazy big Access databases (or ... shudder ... Excel spreadsheets).

Re:So lame

[DarkOx]

They are prefectly capable, and have done so. Actually windows is pretty (NT train on which everything current is based) is pretty cross platform.

What Microsoft can't do is get every other vendor in the world to port all their x86 code, and rebuild all their x86 binaries, where the source is otherwise free of x86 assumptions about pointer size, etc.

FX!32

[DrXym]

Microsoft produced a version of Windows NT for DEC Alpha and threw in x86 emulation layer called FX!32 so it could run existing software. It worked but it ran like a dog, far slower than native x86 instructions. And not for want of trying because it did machine translate instructions to try and execute code natively.

I really don't expect the picture to be any different with x86 over ARM. I expect they'll machine translate x86 instructions into native ARM instructions in some way and cache them somewhere, but the results won't get anywhere close to x86 performance and there'll be a whole bunch of caveats about software it will or won't run. It'll probably be fine for running more sedentary apps.

I very much doubt anybody will be playing Crysis 2 on it. In fact I'd be surprised if any remotely demanding game played on it. Not just just because of the emulation but because no game would be tested with the GPU so they are liable to break hard for one reason or another.

Re:FX!32

[__aaclcg7560]

Now, some dumbass with Microsoft is saying: "The cellular network is the computer."

It is when you consider that the most commonly owned computers are smart phones.

Re:FX!32

[MightyMartian]

If there were lots of ARM desktop systems out there I could understand it, but as it is, ARM is almost solely still an embedded, tablet and smartphone ecosystem. Having used classic Windows apps on an 8" tablet, I can't imagine any sane person wanting to run them on a phone, or even an 8" tablet.

Re:FX!32

[unixisc]

Also, FX!32 was meant to be a stopgap solution until users of major NT titles that were run under the Alpha would prove to the ISVs that it's worth recompiling their titles for the Alpha. Which never happened, due largely to Microsoft's lack of support. It won't happen here either. For some reason, Android succeeded where OS/2 failed - being first to market helped, and the fact that there was another illustrious alternative in iOS ensured that the market had what it needed

Re:Will apples one be app store only or will they

[__aaclcg7560]

Supposedly Apple has Mac OS (or OS X) running natively on ARM processors. The only emulation needed will be for legacy programs, which is what they did for PowerPC programs after switching to Intel processors.

dont count AMD out ZEN intel loses and ARM loses

[Joe_Dragon]

dont count AMD out ZEN intel loses and ARM loses

Re:Dear Microsoft, please don't

[__aaclcg7560]

No, I don't want to write 90% of a web application and then fight your dumb terminal to display it.

You don't support Lynx text browsers? Bastard.

Re:So lame

[jabuzz]

You need to add in the ridiculous licensing on the version of Office shipped with the SurfaceRT (it was Home and Student version so unusable for business) and complete lack of Outlook at launch that basically killed the product.

Re:Code re-writing?

[tepples]

Developers wanted to recompile their x86 Windows desktop applications for the desktop on Windows RT. Microsoft refused, instead decreeing that the only desktop applications on Windows RT shall be File Explorer, IE, and Office.

Re:dont count AMD out ZEN intel loses and ARM lose

[Guspaz]

That's the same thing that AMD has been saying for every new chip for the past decade. They haven't had a hit since the Althon 64, and that was 13 years ago. I'll believe it when I see it, until then, I'll expect Zen to be a repeat of the Bulldozer disaster. I'd like for it to turn out to be another Athlon 64, though: it's been a very long time since there has been any competition in the x86 market.

Data execution prevention

[tepples]

In particular since any emulator that focuses even slightly on performance uses dynamic compilation

Except a lot of mass-market ARM platforms nowadays have W^X security policies that ban dynamic compilation.

Re:Data execution prevention

[Halo1]

That only means you have to mark the pages containing the code you just generated read-only once you're done.

Middle ground between user and ring 0: drivers

[tepples]

If you want application compatibility, not full system compatibility. Emulate 32 and 64 bit user mode instructions only.

Do you foresee ability to plug a peripheral into one of these Snapdragon devices through a USB OTG or USB C adapter and run its device driver correctly?

General purpose?

[tepples]

There is a computer in your microwave oven.

Do these "most commonly owned computers" that you mention offer general-purpose functionality when connected to an external monitor and paired to a Bluetooth keyboard, including the ability to take one tool's output and use it as another tool's input without needing each tool to be specifically aware of the other tools?

Re:General purpose?

[__aaclcg7560]

There is a computer in your microwave oven.

There are computers everywhere. But the smart phone is similar to a PC than microwave oven.

Do these "most commonly owned computers" that you mention offer general-purpose functionality when connected to an external monitor and paired to a Bluetooth keyboard, including the ability to take one tool's output and use it as another tool's input without needing each tool to be specifically aware of the other tools?

GE has a line of Bluetooth-enabled appliances. Not sure about external keyboard and monitor support.

URL:https://www.cnet.com/products/ge-profile-pgb940/preview/?

Re:General purpose?

[Anne Thwacks]

I for one, can't wait to have a keyboard and 27" monitor on my microwave. I just don't want SystemD.

Try a docking station

[tepples]

Having used classic Windows apps on an 8" tablet, I can't imagine any sane person wanting to run them on a phone

Not even on a phone paired to a keyboard and connected to a 24" external monitor?

Re:Try a docking station

[MightyMartian]

I've done it with a tablet and it works, but I own a notebook and have a desktop PC at work so I see little enough reason to do it. In theory I suppose the idea of using a mobile device as your primary computing device has its attractions, but this would also mean for me having a Windows device or a device capable of running the Windows software I do use, and the cost of Windows smart devices is fairly hefty.

Re:Will apples one be app store only or will they

[unixisc]

That would be a good idea. It would enable them to run iOS apps natively under OS X, and leverage the installed base of iOS apps in the Mac space.

Re:Code re-writing?

[Alain Williams]

Or maybe this is an admission by MS that it cannot easily port its stuff to non Intel or perhaps not manage a mixed processor infrastructure (s/ware downloads, updates, ...)

Emulation has got to be slower or use more power (== electricity) to achieve parity.

Re:Dear Microsoft, please don't

[unixisc]

But Microsoft has a horrible record on that - remember NT on RISC? Given that record, I don't trust them on this one. For the Surface Phone, I believe it only makes sense to do if the phone is x64 based, otherwise there is no reason to slay the Lumia. In fact, the Lumia would be a better phone than a phone that still has a Snapdragon but is now emulating x86, as opposed to one running native ARM apps, which is the case w/ Lumia

Re:Intel

[unixisc]

No, even if (take the worst case) x86 dies, Intel can still be a TSMC for the most advanced of semi companies. Don't forget - they also have Altera's FPGAs, and that market won't be going away anytime

3rd party apps lack privilege to re-mark pages

[tepples]

That only means you have to mark the pages containing the code you just generated read-only once you're done.

Several operating systems in wide use, such as Apple iOS and the operating systems of modern video game consoles, offer no way for third-party applications to switch a page from read-write to read-execute. When a page is allocated for data, the OS clears it first, and it stays non-executable until deallocated. Only the OS's executable loader* has the privilege to allocate pages for code, and once the loader loads a module, verifies its digital signature, and flips its pages from read-write to read-execute, the pages stay non-writable until deallocated.

* Or, in the case of Apple iOS, the WebKit JavaScript virtual machine.

Re:3rd party apps lack privilege to re-mark pages

[Halo1]

Given that this is a Microsoft-sanctioned emulator that they will include with their own OS, I think you can be pretty confident it will have similar permissions.

They're trying TCG *again*?

[sethstorm]

Apparently Microsoft hasn't gotten the memo about restrictions not being wanted, so they keep on trying to do it?

Re:So lame

[unixisc]

Not all the apps are written by Microsoft, so they have no control over what gets ported. While they have written Office natively to the ARM viz Office for WIndows 10 Mobile, other apps that the phone may need may not be there.

But I still am not getting the point. The applications that one runs on desktops - not talking about email here - are different from the ones one runs on phones. For instance, things like WhatsApp, Yelp, Fandango, et al are there on Windows Phone, but not on x86: for the latter, one has to open a browser and run from there, or in case of WhatsApp, download the client and make sure the phone version is running. There are a lot of apps missing on the Windows Mobile platform, such as Lyft, Vonage, RetailMeNot, which don't exist on x86 Windows either, so making a phone that runs desktop apps - be it native or via emulation - ain't gonna do a thing for the platform. If anything, the Lumia, whatever its current shortcomings, is certainly more capable than what a Surface phone w/ a similar processor but emulating desktop code is likely to be.

Another point - most of the x86 apps out there are ones written w/ Windows 7 in mind, not Windows 8 or 10, and in that department, they won't do a proper job projecting themselves on a Surface phone