Linked by Thom Holwerda on Mon 12th Jun 2017 20:31 UTC, submitted by dionicio
Intel

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?

Thread beginning with comment 645553
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Just so we are clear...
by galvanash on Wed 14th Jun 2017 04:51 UTC in reply to "RE[2]: Just so we are clear..."
galvanash
Member since:
2006-01-25

And sure enough it uses MMX, SSE2, and even the AES crypto instructions.


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

Reply Parent Score: 2

RE[4]: Just so we are clear...
by Alfman on Wed 14th Jun 2017 13:13 in reply to "RE[3]: Just so we are clear..."
Alfman Member since:
2011-01-28

galvanash,

I have no idea if this is the case or not,


So my word's not good enough, haha, well it's easy enough to verify independently.

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 agree it's possible those exist under conditional code paths, especially where the SSE code was hand optimized. However in cases where the compiler was configured to output SSE instruction throughout the code, it's really not common practice to provide both an SSE and non-SSE version of the code in this day and age since these go back even further than AMD64.

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...


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.

Reply Parent Score: 2

galvanash Member since:
2006-01-25

galvanash,

"I have no idea if this is the case or not,


So my word's not good enough, haha, well it's easy enough to verify independently.
"

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 ;)

Reply Parent Score: 2