Submitted by You’d expect with Microsoft adding x86 emulation to its upcoming ARM-based windows 10 PCs all the possible licensing issues would be sorted. As ubiquitous as x86 is, it’s easy to forget it’s still a patent minefield guarded by Intel. And surprise, surprise, with the chipmaker under pressure from AMD and ARM, it felt the need to make that very, very clear. Dangling at the end of a celebratory PR blog post about 40 years of x86, Intel writes:
However, there have been reports that some companies may try to emulate Intel’s proprietary x86 ISA without Intel’s authorization. Emulation is not a new technology, and Transmeta was notably the last company to claim to have produced a compatible x86 processor using emulation (“code morphing”) techniques. Intel enforced patents relating to SIMD instruction set enhancements against Transmeta’s x86 implementation even though it used emulation. In any event, Transmeta was not commercially successful, and it exited the microprocessor business 10 years ago.
Only time will tell if new attempts to emulate Intel’s x86 ISA will meet a different fate. Intel welcomes lawful competition, and we are confident that Intel’s microprocessors, which have been specifically optimized to implement Intel’s x86 ISA for almost four decades, will deliver amazing experiences, consistency across applications, and a full breadth of consumer offerings, full manageability and IT integration for the enterprise. However, we do not welcome unlawful infringement of our patents, and we fully expect other companies to continue to respect Intel’s intellectual property rights. Strong intellectual property protections make it possible for Intel to continue to invest the enormous resources required to advance Intel’s dynamic x86 ISA, and Intel will maintain its vigilance to protect its innovations and investments.
I’m assuming Microsoft has all this stuff licensed nice and proper, but it’s interesting that Intel felt the need to emphasize this as strongly as they do here. Which companies is Intel referring to here? Maybe Apple?
I hope the world starts moving to ARM.
A RISC-V world would be better.
MIPS, SH, 68K, there’re other ISAs out there that worth a look at.
You mean Android like fragmentation at CPU level?
AFAIK only the RISC-V core is open.
As if ARM isn’t fragmented already? “ARM” is already a hodgepodge of different ISAs and whatever customisation the vendor throws in.
RISC-V would still be a step forward, whatever happens.
Well, there has been an attempt to standardize arm for servers
https://github.com/ARM-software/sbsa-acs
The spec for that itself is arm customer only, but the compliance suite is open source, apparently.
Basically it says you have to use UEFI and ACPI which allows operating systems to know how to boot and how to discover and talk to random hardware.
ACPI and UEFI? Isn’t a device tree the more common way to communicate the hardware information to a kernel on ARM?
Yes, but you have to compile from the device tree for each system you install on. with a UEFI and ACPI, you can use plug-and-play to install drivers on the fly.
UEFI and ACPI won’t magically know the device configuration either. ACPI tables will have to be compiled too for each device.
Changing the bootloader protocol, how the information is passed to the kernel, does not change the fact the information has to come from somewhere.
Yup. RISC-V and SPARC are just about the only mainstream ISAs without legal minefields attached to them.
I don’t think either MS or Qualcomm have much to worry about here. They’re not replicating any of the uarch stuff that is what’s patentable.
It probably will fall into some sort of copyright issue, but I doubt Intel can forbid anything having to do with binary code they haven’t produced, even if it uses their ISA.
If anything the bigger issue is the power efficiency of the emulation, rather than Intel’s FUD.
Edited 2017-06-13 22:40 UTC
Wouldn’t that move you from one patent minefield to another? Make no mistake, ARM is as well protected as intel, thy just let other people manufacture.. right now.
We should jump out of the frying pan, the flames are much better!
ARMv2 at least isn’t patented anymore. Anything newer is potentially or guaranteed littered with patents from a company that will aggressively defend anything patent related. And they have resources to sue anyone they want.
RISC-V is a better choice though it isn’t really innovative (not a real problem).
Intel must realize it’s on dangerous ground here. Legally speaking they could find a court willing to block competing x86 implementations, but they will likely loose favor in the public eye if they start pursuing unpopular patent infringement lawsuits over x86 emulation. IMHO intel should stay focused on their advantages instead and invest that money in making their CPUs better.
Can’t remember where I read It, but seems you can’t demand wherever you like, anymore.
Yup. Happened recently, too
https://arstechnica.com/tech-policy/2017/05/supreme-court-makes-it-m…
From what I have been reading, it is not the x86 original/base instructions set but the current and way newer SIMD (SSE), VT and other extensions that are really the reason to worry. Not sure though.
Granted, if you don´t have a way to emulate these new tech, specially on-core, you are going to suffer from performance and usability.
I think the real target of Intel comments are the other hardware designers, not Microsoft, primarily.
Sure, such improvement, SSE, SSE2, SSE3, SSSE3, SSE4, SSE5, … Iterative “improvements” to reset patent watchdog at regular intervals. Clock is tickling at metronomic rate.
Also they can’t block implementations of the ABI, just for being the same ABI. Only for using the patented techniques.
Would they need to get a license from Intel?
(do they already have one?)
Virtualbox is not an emulator… It is virtualization.
x86 Emulators (like Bochs) actually emulate the entire processor, as such they have to actually implement instruction decoding, execution, and what not (things the patents that Intel holds apply to). Bochs would technically need a license, but there is no money behind it so Intel seemingly doesn’t bother to threaten them.
Virtualization does not do that. When you run stuff on Virtualbox your just running native x86 code directly on the underlying processor. Virtualbox emulates I/O devices, or more accurately proxies access to them so that the virtualized environment thinks it has its own dedicated I/O devices. It more or less acts as a traffic cop, marshaling access to the devices that need to be proxied. There is very little “emulation” involved with it (other than the device drivers themselves).
Intel doesn’t require patent licenses for such software – they actually encourage use of virtualization – because you need an x86 processor to run it on…
Edited 2017-06-12 22:18 UTC
VirtualBox can emulate an x86 if you have VT-x disabled in the BIOS, I ‘ve tried it. VMware couldn’t.
Edited 2017-06-12 23:21 UTC
VT-x is hardware (ie. CPU based) support for the virtualisation. Without VT-x you may still use software virtualisation based on i386 capabilities and this is just slow, but it works. It could be speeded up by modifications of the virtualised system, but it is impossible for Windows as you have no source code and Microsoft will do nothing to help you. .
Are you sure that “software virtualization” isn’t just, you know, emulation? Or is there actual dynamic recompilation happening?
There are various approaches, but in simple terms it is just trapping on all memory access instructions and rewriting the segment addresses in the instruction stream. Its an elaborate form of segmented mode + some privilege ring manipulation.
Call it what you will. I have heard the term binary translation used to describe it and that seems appropriate. I just think calling it emulation is a bit much…
Edited 2017-06-13 00:18 UTC
Yeah, I would not call that emulation since the machine code runs on the host CPU, just with trapped instructions. Whether this happens beforehand with a recompilation (similar to a linker) or at runtime with traps is not so important.
Why would you need to do dynamic recompilation on when running x86 on x86… you don’t. You just need to trap hardware accesses and such.
Its still not full emulation, it just trap-and-handle on specific instructions and doing some fancy translation of the instruction stream (yes, oversimplified, but mostly accurate). Even with VT-x disabled, you are still passing the vast majority of instructions through to the CPU as is, your just doing fixups of specific instructions before they reach the CPU.
Most Virtualization software stopped supporting this approach ages ago. Even Virtualbox no longer supports it for 64-bit code (VT-x or AMD-V is required for 64-bit guest OS). Its mostly just left in there for people running 32-bit stuff on really old CPUs – VT extensions are significantly faster when available.
kurkosdr,
An interesting side effect of this is that because the recompiled code can be run through an optimizer, you could theoretically get even better performance under emulation than running the original code natively (the original compiler might not have been able to produce as highly optimized code as QEMU). This would be interesting to test in practice.
Back to the topic at hand though, I guess intel’s just been turning a blind eye to x86 emulation. I wonder if they’ll just go after microsoft x86 emulation or if they might seek to shut down projects like qemu as well.
Hi,
No.
Software is very different to hardware, and (even for the “no VT-X” case) it’s very unlikely that a software emulation will infringe Intel’s hardware patents.
The problem here is that Qualcomm are doing/planning hardware emulation (and not software emulation), and therefore it’s far more likely to infringe on Intel’s hardware patents.
– Brendan
Brendan,
Apparently only x86-32 emulation will be supported, which I find kind of odd. If this had been engineered from scratch, the lack of 64bit seems like an obvious omission. I get the distinct impression this limitation is a carryover from the emulator’s origin. I’m thinking it’s the same emulator microsoft used to run x86-32 code on IA64 (itanium). They took the existing emulator and ported it to ARM64. The IA64 x86 emulator never supported AMD’s x86-64 extensions and x86-64 ended up replacing IA64.
They probably discussed using QEMU and it’s full 64bit emulation, but then microsoft would have had to comply with the GPL.
Edited 2017-06-13 04:59 UTC
Hi,
The idea would be to translate blocks of 80×86 code directly into efficient equivalent blocks of ARM code. This means that the only part they’d be able to take from a previous “80×86 on Itanium” emulator is the front-end (decoding, etc) without any of the back-end (optimisation, instruction selection, etc).
Note that I doubt they would’ve considered Qemu. Its software emulation mostly just stitches together compiler generated snippets; which is far more portable, but wouldn’t be anywhere near acceptable for performance.
As a random estimate, binary translation done well should be about 90% of the speed of native code (and Qemu’s software emulation is only about 15% of the speed of native code, even for “80×86 guest on 80×86 host”). Also, don’t forget that these Qualcomm CPUs are at a performance disadvantage already (e.g. 1.5 GHz Qualcomm vs. 3.5 Ghz Intel), so they can’t afford too much “emulation overhead” on top of that.
– Brendan
Brendan,
I think Qemu’s software emulation (not VT-X) is actually better than that, I might run some benchmarks and get back to you. It’s not like bochs where it has to emulate every cpu cycle and incur a significant overhead for it.
Brendan,
I’ll have to give you this one, I measured qemu’s software emulation performance using sysbench, and its performance was 18% of native. I agree that software emulation run through an optimizer should be much better than this, but I guess qemu’s software emulation hasn’t received much attention with the advent of kvm. With kvm enabled it is 100%, which is not surprising.
It will definatly be interesting to see benchmarks of microsoft’s x86 software emulation.
Just for comparison, itanium’s x86 emulation back in the day had similar overhead.
https://tweakers.net/reviews/204/8/intel-itanium-sneak-preview-bench…
Hi,
What they described is the general concept of binary translation; without mentioning any details of how it’s implemented (e.g. and whether it’s just stitching together snippets without any optimisation, or not).
However, the video did say something about caching “translated blocks” on disk; which (to me) suggests that they’re not doing a “fast un-optimised translation” and are probably doing “slower optimised translation” (and want to cache it to avoid the overhead of optimisation next time).
– Brendan
Brendan,
Well, x86 acceleration would be extremely newsworthy, however everything I am seeing, including the video from microsoft’s own engineers above indicates it’s software emulation and not hardware accelerated. Even qualcomm’s own specs for this processor doesn’t have any mention of x86 acceleration, surely it would be relevant:
https://www.qualcomm.com/products/snapdragon/processors/835
https://www.qualcomm.com/news/onq/2017/01/03/meet-snapdragon-835-nex…
So I’ll be happily surprised if there is hardware acceleration for x86, but I doubt it. We’ll see soon enough what the benchmarks say, I’m definitely curious!
I’d love to have a good selection of ARM PC products capable of running both windows and linux, but I’m really afraid that these windows PCs on ARM64 will be vendor locked to microsoft. I hope I’m wrong
Hi,
For this I’d assume “UEFI Secure Boot” where other operating systems (e.g. Linux) can work fine as long as they’re digitally signed with Microsoft’s key.
– Brendan
Brendan,
This doesn’t help me at all with my own builds. Frankly this ought to be illegal, owners should have the explicit right to replace microsoft’s keys on their computer with their own!
Edited 2017-06-14 20:16 UTC
Not necessarily. They’re trying to play up their relationship with Qualcomm for these new devices – they have no reason to mention support with other manufacturers while also talking up their new relationship with Qualcomm.
Supporting 32-bit only code is probably how they’re avoiding Intel’s patents. Regular 32-bit x86 won’t be covered by any patents anymore. x87 and MMX won’t be, either, and patents on SSE will expire within a couple of years (If they haven’t already – depends on when they were filed, but the first PIII came out in ’99)
However, SSE2 patents are good for another few years, and AMD made SSE2 a mandatory part of x86-64, so emulating x86-64 means emulating SSE2, which could cause legal problems.
Maybe that’s the reason Microsoft are only emulating X86-32
SSE2 patents are long expired. SSE4.1 and AVX patents though.
SSE2 was first released in 2001, with the Pentium 4. unless they patented it before SSE was even released in 1999 (Very doubtful), we’ve still got a few years before SSE2 patents expire.
Remember: Patents last 20 years.
QEMU is an order of magnitude slower. This is not even an option
Edited 2017-06-13 09:00 UTC
Other than microcode a favor to Intel, occupy ALWAYS LIMITED mind-real-state -a winning over competing architectures-.
But of course, not everyone within a Corp able to focus at the horizon.
IP exchange could be a way of avoiding Lawyer’s Houses ruining a quick go forward.
Cross licensing also.
Not sure why it would apply to Apple as Apple moved to Intel and can move off just as easy. They don’t need to emulate X86 to do it.
Only company talking about this is Qualcomm on ARM. They better watch out! Lol.
Because there has been serious talk of Apple using their own CPUs exclusively and using some sort of emulation to allow the X86 code to run for a limited time, similar to the fat binaries they had when they switched from PPC to X86.
You have to remember Cook was originally was in procurement, he knows how a single weakness in your supply chain can bone a company and the mess with Qualcomm I’m sure has driven that point home.
This came up a lot in 2011. And at the time many speculated on an x86 to arm version of Rosetta. Which seems to be what the speculation is here.
But apple abstracts the API much further these days. In fact Apple polices it’s API much more aggressively that Microsoft. And according to many speculators, Apple has seen this coming for a long time. So it would not surprise me if any transition required minimal code alteration to compile for ARM. As most of the chip instruction set is abstracted away from the end user.
IMHO i think Apple should build a dual-architecture machine. By using a small ARM chip to handle the operating system overheads (such as memory management, drawing the UI etc) you’d be able to unload a lot of work from the Intel CPU, freeing it up for high performance workloads, such as video rendering and audio production. That way, you’ll be able to max out the Intel core whilst keeping the OS slick and responsive. Of course, smaller low-performance apps, such as a browser, text editors etc could be compiled to run directly on the ARM core too, allowing the Intel cpu to be switched off if it’s not in use by a high-performance app
I think computers are already dual architecture, or even triple, as many SOCs include an ARM core taking care of low level stuff.
There is almost no way that is currently true. There was no announcement of any licensing agreement from Microsoft or Qualcomm, and considering they are basically giving this version of Windows away (and it is an outright threat to Intel’s business model), there is no conceivable upside to compel Intel to offer licensing. In short, while it is possible, it is very unlikely.
Besides, historically Intel doesn’t license anyone voluntarily (at least not in the last 20 years). Every holder of x86 patent licenses still enforcable got them through litigation settlements – which basically amounts to AMD and to a limited extent VIA and nVidia (the latter does not seemingly extend to x86 architecture though).
Everything else still in existence is either pre-MMX 32-bit x86 (upon which all relevant patents have expired), or blatantly ignoring them (Loongson, various open source products, etc.)
I’m fairly sure this press release was aimed directly at Microsoft and Qualcomm. Consider this a stern warning that Intel will respond legally if they feel the product violates their patents in any way, or alternatively opening to negotiations if Microsoft/Qualcomm are not 100% sure they are on safe legal ground (and be ready to pay through the nose)…
ps: It is entirely possible the x86 emulation they are planning does not violate Intel’s patents. It depends on how far they go. 32-bit only x86 with no MMX/SSE/SSE2/FMA etc. extensions would conceivably be doable – because all of the relevant patents applicable to that have expired by now. Basic MMX might be possible as well, but it’s debatable. Anything beyond that though and they are poking the bear. Maybe they got clever about it though, who knows.
This is the video that all the current info comes from:
https://sec.ch9.ms/ch9/77bc/0cb602d9-0828-49f9-a291-c17b26c377bc/P41…
(The demo-parts are from roughly 2:30 to 5:30 and around 12:00)
Basically they show that;
* Windows 10 Pro for ARM is a 64 bit OS that can run on 4 BIG and 4 LITTLE cores
* Because it is Pro you can also do things like a domain-join
* That OS runs natively and so do the build in store-apps
* Drivers for peripherals will be based on generic class drivers
* 7Zip (32 bit!!!!) can be installed just like on a normal 64 bit Intel machine and will end up in the c:\Program Files (x86)\7Zip folder (There was a previous demo of PhotoShop but no background/OS-info as far as I know, but I assume that was a 32bit PhotoShop as well)
* Store-apps and the store itself seem to be 32bit for reasons unknown to me but will run natively/compiled-for-ARM
* Most apps that are compiled for ARM should just work
The general idea about this “Windows on ARM” version is that it will be aimed, similar to Continuum, at light-and-portable devices where batterylife is more important than performance, just like the old Windows RT. However, where Windows RT failed because of an empty store, lack of hardware choice and no other software there is now a lightly filled store, there will be more hardware choice with much improved performance and there will be support for legacy 32bit applications.
“Windows on ARM” will not be meant for heavy gamers, video-encoding or servertasks!
Edited 2017-06-13 11:50 UTC
Thanks, Galvanash. Those are my memories, too. Hopeful those destructive behaviors doesn’t replicate. The effort is on continuity, on legacy.
And that is a tribute to peace times. You can’t go far, if having to start from the start line, every time.
Is AMD about to do something amazing that Intel caught wind of?
That would make sense, AMD and Intel has a cross license agreement, that is why AMD are allowed to make x86 processors and Intel are allowed to make x86-64 processors.
BTW, I am really eager to find out how far MS and Qualcomm are willing to go on that “running x86 code” thing. Now, don’t get me wrong, I don’t expect to boot Windows 7 on it, but will it be a full emulation of -say- the Pentium III ISA, or some “accelerator” thing helped by software?
Qualcom was announcing some interesting stuff due to be launched in Q2 2017 (like 48 core server chips on the new 10 nm design).
Looking at what AMD did with Ryzen, this can be a big hit for Intel in the data center land as well (where they also kept the focus some some years now).
Even on the software side things are moving slowly to ARM. Running x86 code is more like running legacy code these days.
They could slice the market: Intel up, ARM down, AMD middle grounds ;D </EndOfBabbling>
… just a couple more layers down.
Without arguing one way or the other about whether implementations should be patented, clearly specifications like the ISA should be treated like the Java API or .h files. Let anyone implement a compatible version. Good for competition.
License the name “Intel-compatible”
FunkyELF,
To be honest I didn’t like the outcome because now courts have to apply the standards for copyright to APIs, in other words they are copyrightable in the US. This precedent means that we cannot assume APIs can be reimplemented without infringement, instead we must go to court to fight for a fair use exception on a case by case basis. Google’s final case was a narrow win that only applied to google’s case. This really sucks for software developers because APIs exist to serve a functional purpose rather than an expressive one and we can’t know whether or not our re-implementing of an API will infringe – it will depend on the technicalities/judge/lawyers/etc.
Edited 2017-06-13 19:57 UTC
The most important patents Intel had on x86 are all expired… AMD owns all the amd64 patents that matter, if some of Intel’s SMID instruction sets dropped off the face of the earth noone would bat an eye….
You’d be surprised how much code depends on MMX/SSE/AVX instructions.
tylerdurden,
For kicks, I ran the objconv disassembler against 32bit 7zip (this is significant because microsoft’s x86 emulation demo specifically shows 7zip).
http://www.agner.org/optimize/#objconv
And sure enough it uses MMX, SSE2, and even the AES crypto instructions.
pxor
movdqa
paddq
aesdec
aesdeclast
It appears these instructions are only present in selected loops inside 7zip, so these code paths were probably optimized by hand.
chrome uses SSE1, SSE2 and SHA instructions
sha256rnds2
ucomisd
mulsd
These vector instructions are dispersed throughout the chrome code, suggesting the compiler flags were set to enable SSE auto-vectorization.
ekiga does not appear to use SSE
firefox uses SSE1, SSE2
vlc uses SSE2
putty does not appear to use SSE
teamviewer uses SSE1, SSE2 throughout code.
thunderbird uses SSE1, SSE2
…
This isn’t very comprehensive but I think it’s safe to say that a lot of 32bit windows software has been compiled to target SSE2 at least.
I have no idea if this is the case or not, but just because the binary has those instructions in it does not mean that Microsoft’s emulator supports executing them. The binary could have been compiled with alternate code paths for CPUs that don’t have the correct feature flags – the instructions would still be in the binary, just dormant when run on CPUs not reporting support for them.
I could be totally wrong too, I don’t know. If they are actually supporting and executing SSE2 and AES instructions in their emulator they are going out on a limb legally…
Edited 2017-06-14 04:54 UTC
galvanash,
My “genuine intel” processors do not support AES/SSH extensions because those are relatively new, so we can assume those are conditional.
As to the legality question, it’s a crappy situation. AES/SSH are not new, intel didn’t even invent them, the incorporation of AES/SSH instructions behind some opcodes is absolutely trivial to anyone familiar in the art of crypto and assembly language, and yet despite these facts we genuinely don’t know whether intel could successfully sue someone for emulating them.
Sorry, I meant that “I” had no idea or not as to whether the binary was compile with alternate code paths or not. I wasn’t questioning your findings
galvanash,
Not a problem, it’s something we could chuckle over in person, but didn’t come across online
Speaking of which, is anyone in the NY/long island region?
AMD have a number of patents related to AMD64 and other x86 things.
shouldn’t the older Patents be expired by now? or has Intel pulled a Disney, and were able to get the parts of the law covering the patent expiration extended.
My next speculation is that Qualcomm could have (discretely) micro-coded whatever no longer enforceable, and on slooow emulation whatever still is.
Not believing Provider choice, on simple philia.
Being performance hit 3X% at general office applications, on sliding from 64b to 32b, worth the bite. The legacy they’re fighting to carry on, is at that slice.
Some other place I read on Qualcomm being a little overconfident over this [such a little Actor, come on]. So, the bravado should be on this avenue.
Edited 2017-06-15 15:22 UTC
dionicio,
“From Alfman<>Brendan ideas exchange…”
Your title made me chuckle, it makes it sound like Brendan’s my nemesis, haha.
Is this what it’s like being on LSD?
That’s what it’s like being on machine translation. Not that hard to understand IMHO.
Answer to that post:
—
Yes Qualcomm is a small part compared to Intel but much smaller companies have successfully designed x86 processors – one in particular executed x86 via microcode on a RISC processor. IIRC not really a translation based design and with a real RISC core with very few changes rather than the “RISC” cores some say Intel and AMD have inside (they are CISC). Sadly don’t remember the name of that company.
Partial emulation of those x86 parts still patented should be okay – most patents are about how to efficiently execute instructions in hardware and not emulating them with more or less significant performance impact. How easy it would be to combine that emulation with hardware support for non-patentable core features is harder to answer. The various instruction encoding extensions (REX, VEX etc.) are probably patented which would require trapping at instruction decode and doing the parsing in software (to avoid using hardware) which could be very expensive time wise.