Rumor: Microsoft Working on x86 Emulation for ARM64

Subject: General Tech | November 25, 2016 - 07:01 AM |
Tagged: x86, windows 10, microsoft, arm

According to Mary Jo Foley at ZDNet, Microsoft is working on emulating the x86 instruction set on ARM64. Her sources further claim that this is intended to be a Windows 10 feature that is targeting Redstone 3, which is the feature update expected in late 2017 (after the upcoming Creators Update in early 2017). Of course, Microsoft will not comment on this rumor. Mary Jo Foley is quite good at holding out on publishing until she gets multiple, independent sources, though. Still, projects slip, pivot, and outright die all of the time, even if the information was true at one point.

View Full Size

Media Center is still dead, though.

So, while keeping in mind that this might not be true, and, even if it is, it could change: let’s think.

The current speculation is that this might be aimed at enterprise customers, including a potential partnership with HP and Qualcomm. This makes sense for a few reasons, especially when you combine it with Microsoft and Samsung’s recent efforts to port .NET Core to ARM. Combining rumors like this might be akin to smashing two rocks together, but you never know if it’ll spark something. Anyway, you would expect these sorts of apps could jump architectures fairly well, because they’re probably not real-time, form-based applications. You might be able to get a comfortable enough user experience, even with the inherent overhead of translating individual instructions.

Another possibility is that Microsoft hasn’t given up on the Windows 8 / Windows RT vision.

Back in that era, the whole OS seemed designed to push users toward their new platform, Metro. The desktop was an app, and that app contained all of the Win32 bits, isolating them from the rest of the PC and surrounding that tile with everything WinRT. The new platform was seductive for Microsoft in a few ways. First, it was more secure, and people considered Windows the operating system that’s plagued with malware. Second, it let them assert control over their apps, like Apple does with their App Store. At the time, they even demanded that third-party web browsers be nothing more than re-skins of Internet Explorer. Firefox? Don’t even think about bringing Gecko in here. It’s Trident or bust.

Say what you like about those first two points, I know I have, and often disapprovingly from an art enthusiast standpoint, but there was a third one that also interested Microsoft:

Hardware independence.

The WinRT runtime, when it was first unveiled, was pretty much designed in a way that Microsoft could swap out everything underneath it if they wanted to jump ship and move to a new architecture. At the time, almost a decade ago, Intel wasn’t competitive against ARM in the mobile space. This kept Windows applications, and Microsoft, watching the rest of the world sail away.

But supporting both ARM and x86 isn’t good enough. What if IBM wins next time? Or a completely different instruction set? If everything calls an API that can be uprooted and transplanted elsewhere? There will never need to be this mobile concern again.

But then we have this whole decades of stuff that already exists problem. While I don’t like the frog boil analogy, it could be Microsoft’s attempt to uproot enough x86-locked content that people can accept UWP. I’m not sure that will work out, especially since we rely upon real-time software that is not accepting Windows Store, but it might be their goal.

What do you all think?

Source: ZDNet

November 25, 2016 | 11:53 AM - Posted by John H (not verified)

I always assumed the x86 translation to run on ARM was something they'd do with future versions of WinRT -- keep the core OS ARM, and some key applications get a recompile to ARM, but then extend the ability of ARM to run x86 for "legacy" applications.

Major ARMv8 processors are much wider issue, and have way better caches and memory performance than when WinRT first launched which should make the performance at least usable in many cases.

The emulation of other architectures is quite tried and true - I first used PC Ditto which provided approximately PC XT speeds and let me run DOS applications on my Atari ST (8 mhz 68000) back in the 1980's. Certainly modern processors have a lot more instructions to emulate, but Microsoft IS an army of programmers.

Microsoft needs to do this NOW to build up some ecosystem of support around ARM running Windows to avoid / slow down continued siphoning of their market by Android and iOS products.. Even if this isn't perfect, you can always argue that Windows IS easy to use and familiar to a lot of people, and the price points of ARM products are unbeatable (see: Intel atom failure, AMD Cat cores not doing much better). ARM is also clearly growing up with the latest Apple processors performing as well as desktop Core 2 Duos..

November 25, 2016 | 11:59 AM - Posted by Anonymous (not verified)

There really is no need to run pure x86 applications on ARM, as there are plenty of ways to port over any pure x86 applications to run under Power8/Power and ARMv8A or other ISAs. The real problem is that we are talking windows desktop applications that use the windows 7/8.1/10/earlier APIs that are in fact x86 based windows applications. That requires the necessary windows OS/API subsystems to actually function and that's quite a bit of abstraction levels in and of itself that requires a fair bit of overhead no matter the intended ISA that it runs under.

There is the other fact that any windows API based desktop applications require lots of windows OS API/code calls that are optimized for Intel's brand of x86, under Intel's brand of CPU hardware cache subsystems/etc. using Intel based compilers that are optimized for Intel's CPU hardware. There are whole libraries of code created using these CPU optimization manuals for Intel's specific x86 hardware so OS programmers can tweak their machine language code to not cause any undue CPU cache thrashing, or undue CPU execution resources utilization issues etc. These tweaks are baked into some of the windows OS kernel code and have to be re-factored when ported over to another ISA, and even AMD's x86 ISA based CPUs have cache memory subsystems differences/microcode/other differences that need to be optimized for when compiling for AMD's various x86 based CPU cores.

Add to all that the x86 16/32/64 bit ISA legacy bloat and that’s a whole other level of insanity inducing prospects for any emulation abstraction going from any CISC based ISA to any RISC based ISA. Some of this takes a very long time to sort out as the legacy windows OS API bloat and windows application bloat has had a very long time to build up around the x86 16/32/64 ISA over the years with respect to the windows OS/API/application ecosystem for both Intel’s and AMD’s brand of x86 16/32/64 ISA based CPUs.

November 25, 2016 | 01:02 PM - Posted by Anonymous (not verified)

P.S. If you where to look at both AMD's and Intel's x86 assembly language instructions at their decoded level and look at the actual differences in how AMD’s and Intel’s underlying hardware actually has decoded the same x86 machine language op-code instruction at the microcode/sub-assembly op-code level there are differences. And after each respective CPU makers’ decoder hardware has decoded that same x86 instruction into its decoded form, that decoded instruction may look radically different as both AMD's and Intel’s underlying hardware that implements the x86 ISA is very different between Intel’s and AMD’s respective custom micro-architectures that are engineered to run the x86 ISA.

The assembly op-code/compiler optimization manuals created by each CPU maker that have more information as to what AMD’s and Intel’s respective underlying hardware produces as the result of any x86 assembly language op-code decoding into a from that will be directly executed on each CPU makers different underlying hardware implementations are pretty complicated. So each maker's proprietary CPU hardware that is engineered to run/execute the standardized x86 ISA can require different optimizations at the assembly language/compiled into x86 code level for optimized performance on AMD’s or Intel’s respective CPU hardware. There are even differences from one of Intel’s x86 CPUs to another of Intel’s x86 CPU hardware that may have different feature sets enabled or disabled, ditto for AMD’s various x86 makes and models of CPU and even differences at the CPU stepping number level for that same CPU make and model.

Porting over an OS from one ISA to another ISA is a herculean task and add to that task the code re-factoring when porting over from a CISC ISA to a RISC ISA and the process can easily boggle the mind. Then add to that the re-optimization process that has to occur under the new ISA based CPU hardware for any OS/API code and code libraries and things can take years and longer to achieve and cost billions of dollars!

November 25, 2016 | 11:54 AM - Posted by Anonymous (not verified)

And a symlink to the very same subject! Oh well!

"WoW, Microsoft is back in the porting business again. x86 to ARM expected with Redstone 3"

November 25, 2016 | 12:44 PM - Posted by JohnGR

We have seen processors emulating x86 in the past, but back then, you usually needed every little bit of performance from your processor, so those processors failed( Transmeta ). Today most cores are asleep or underutilized, so maybe we could expect in a few years to see more x86 emulation on ARM devices. Probably what I am thinking it is something different from what it is rumored that MS is doing, but I think we will eventually go there. MS have to get into the ARM market before Android starts invading laptops and desktop more seriously.

November 25, 2016 | 01:38 PM - Posted by Anonymous (not verified)

Yes and not very efficiently at the cost of usability. And we are talking about doing this with the bloated over the decades Windows OS/API and desktop software ecosystem with it's decades long legacy dependencies that can not be overlooked when running windows desktop applications.

It was relative easy for Apple to convert over from PowerPC to x86 because of Apples(1) BSD based OS Kernel and relatively light legacy software dependencies under a Unix like BSD derived(OS X) OS kernel. Also there was Apple's Rosetta(2) that was a user level translation layer for security reasons and had limitations. CPUs at that time 32 bit CPUs where a little less harder to produce emulators for when Apple went over to x86 from PowerPC. PowerPC is a RISC based ISA so much simpler to emulate.



Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote><p><br>
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.