
Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield - Analemma_
https://arstechnica.com/information-technology/2017/06/intel-fires-warning-shots-at-microsoft-claims-x86-emulation-is-a-patent-minefield/
======
rayiner
This marks a distinct shift for Intel. Historically, Intel's IP approach has
focused on trade secrets, because they had a huge advantage in manufacturing
and implementation techniques that are not easily reverse-engineered. Patent-
protecting x86 didn't make much sense during the long period where nobody
could make a general-purpose CPU as fast as Intel running native code, much
less while emulating x86. As Moore's law has run its course, Intel's lead on
that front has been shrinking. Apple's A10 is shockingly close to matching
Kaby Lake on performance within a similar power envelope. And Ryzen is within
spitting distance of Broadwell at the high end. All on non-Intel foundry
processes. That was unimaginable 10 years ago.

~~~
_delirium
That's the opposite of my impression of their history. Intel's approach to x86
historically has been asserting that it's basically impossible to implement a
clone due to their patents, which they aggressively asserted to keep any
competitors out of the market entirely if possible, and restricted to older
ISA features if not possible. With the main exception of AMD, which was
initially given patent licenses and tolerated in order to meet 2nd-source
requirements. But even AMD they tried to strongarm out of the market later,
leading to litigation where AMD eventually won a bunch of continued patent
licenses only as part of the lawsuit settlement. Intel has also used patent
lawsuits over the past 30 years to attempt to limit competition from Cyrix,
Via, NVidia, and Transmeta, among others. Though they did lose or unfavorably
settle a number of those lawsuits.

~~~
tinus_hn
It's kind of difficult to believe this when the relevant architecture of today
(x64) was developed by AMD. X86 is ancient, any patents that can't be avoided
would have expired years ago.

~~~
sqldba
I'm always surprised when I read this. How long do patents last? I'd always
thought they were indefinite or like copyright.

~~~
ghaff
No. Patents are generally valid for 20 years from the initial filing. The idea
is that you get a limited term monopoly in exchange for making the details of
an invention public.

------
amorphid
Attorneys on both sides must be excited on some level about the potential
number of billable hours it'd take to litigate a case like this. Reminds me of
a something an entrepreneurship professor told me...

If there's one lawyer in town, they drive a Chevrolet. If there are two
lawyers in town, they both drive Cadillacs.

~~~
blazespin
To be fair Intel has done a lot of work to make the x86 as great as possible.
Patent lawsuits are awful. I'm not sure just copying someone's technology and
emulating it without paying a license fee is all that great either.

My guess is this is all just negotiation from Microsoft's point of view and
they are just trying to get Intel to license the ability to emulate x86.

Another possibility is this is a way to get Intel to invest more resources (
even at a loss) into competing with ARM.

~~~
pcwalton
Emulation is only an implementation of the ISA. The x86 _ISA_ is hardly "as
great as possible". In fact, it's downright crummy: x86-64 is as bloated as
RISC architectures usually are without any of RISC's benefits. At best you can
make the argument that x86 has done well _in spite of_ the ISA, not because of
it.

The silicon-level implementation is another matter entirely, of course--but
emulation has nothing to do with that. In fact, that's the definition of
emulation--using a completely different implementation to offer a compatible
interface.

~~~
rayiner
x86-64 is a perfectly acceptable ISA. Strong memory ordering, no architectural
optimizations leaking out like branch delay slots or stack windows. Pretty
good i-cache efficiency through the use of two-address code and memory
operands. Of course, Intel didn't have much to do with it. Most of it is
either an accident of history or the work of AMD, who a lot of work
regularizing the ISA in the 64-bit transition.

~~~
pcwalton
1\. Yeah, ARM has one nasty architectural optimization leaking out: the
program counter register being 8 bytes ahead of where it should be due to
pipelining. Thankfully that got fixed up in AArch64, and if 32-bit mode gets
dropped down the line (which is allowed by the architecture) it'll be a thing
of the past. x86 has some architectural leaks too, though: the aliasing of the
MMX and FP stacks as a hack for compatibility with early versions of Windows
comes to mind. This one hasn't been fixed.

2\. The REX prefixes are a nightmare: most instructions have one and this
tremendously bloats up the instruction stream size. For this reason, the
i-cache efficiency is _not_ good compared to actual compressed instruction
sets such as Thumb-2 (not that Thumb-2 is wonderful either). Note that if you
do extreme hand-optimization of binary size, you can get x86-64 down pretty
far, but so few people do that that it doesn't matter in practice.

3\. Two address code isn't necessarily a win, especially since it doubles the
number of REX prefixes. In AArch64 "and x9,x10,x11" is 4 bytes; in x86-64 "mov
r9,r10; and r9,r11" is 6 bytes (and clobbers the condition codes). There's a
reason compilers love to emit the three-address LEA...

4\. Memory operands are nice, though I think the squeeze on instruction space
makes them not worth it in practice. I'd rather use that opcode space for more
registers.

5\. Immediate encoding on x86-64 is crazy inefficient. "mov rax,1" is a
whopping 7 bytes.

~~~
kccqzy
Regarding 5, no, it's five bytes (b8 01 00 00 00) for movl $1,%eax. If you
actually have a 64-bit immediate, just the immediate itself would be 8 bytes,
and the actual instruction is 10 bytes.

~~~
besselheim
MOV RAX, 1 is seven bytes: 48 C7 C0 01 00 00 00

~~~
pcwalton
The parent has a good point actually, because "mov eax,1" automatically zero-
extends in 64-bit mode.

It's still one byte longer than the equivalent AArch64 instruction, though.

~~~
kccqzy
Fine. If you are really into getting the shortest instruction, try "xorl
%eax,%eax" then "incl %eax" which is four bytes (31 c0 ff c0).

~~~
gsg
push $1/pop %eax (6a 01 58) is shorter, but perhaps not the best idea.

~~~
nayuki
Actually, there is no 32-bit pop instruction in x86-64 mode. Your code won't
work.

~~~
gsg
You're right: it should be pushq $1/pop %rax (which is also three bytes,
although there will be a prefix byte for registers r8 through r15).

------
Deinos
The article mentions Cyrix as a "victim" of Intel patent defense; however,
Cyrix not only won their lawsuits, but they also went after Intel for patent
violations in the Pentium Pro and Pentium II processors.

[https://en.wikipedia.org/wiki/Cyrix](https://en.wikipedia.org/wiki/Cyrix)

[http://law.justia.com/cases/federal/district-
courts/FSupp/84...](http://law.justia.com/cases/federal/district-
courts/FSupp/846/522/1687321/)

~~~
std_throwaway
You can win a lawsuit and still lose so much time and money on the way that
you are worse off afterwards.

Vice versa you can cause your opponents so much trouble with lawsuits that -
even though you don't win them - you are better off than them afterwards.

~~~
rhaps0dy
But Microsoft is bigger than Intel. So if anything, they will cause trouble to
Intel.

~~~
std_throwaway
Both can afford to spend hundreds of millions on a lawsuit. The lawsuit will
be only a part of the budget for both and non-existential. So I don't think
that the size matters here.

It would be different if the lawsuit is so expensive that one party could go
bankrupt due to it.

This isn't about right and wrong. It's about money. Who has to pay how much to
the other party? Both parties think they are better off if they fight. Both
parties think they could win money in the end. It's a gamble in the courtroom.

~~~
chongli
The stakes could potentially present an existential risk to Intel. Imagine if
Microsoft won and transitioned all Windows customers to ARM. That would be a
huge blow to Intel's market!

------
amalcon
Years ago, I spoke with an attorney with a CS background. He had once worked
on a case like this. Sharp guy. He didn't tell me the parties involved, and I
didn't ask, though I assume he wouldn't speak openly about it while it was
ongoing. I therefore don't know how it turned out. It was many years ago, so I
might be remembering wrong. I'm not a lawyer, this is not legal advice
(neither mine nor his).

Basically, there are two approaches the plaintiff might take here. The
simplest is to cite the doctrine of equivalents[1]. This is basically the
notion that if you do the same thing in the same way for the same purpose,
then it's the same process, even though you are using digital instructions
instead of logic gates. The legal theory here is pretty well settled. The
problem is that you'd need to justify that digital instructions are obviously
equivalent to logic gates, and a skilled professional would have equated them
at the time of the patent's filing.

The other approach is to argue that an emulator actually is a processor, and
therefore fits the literal claims of the patent. The explanation for this is
pretty well-established: it's literally the Church-Turing Thesis[2]. However,
the viability of this argument depends on the language of the patent claims.
Also, it's hard enough to explain the C-T Thesis to CS students. My undergrad
had an entire 1-credit-equivalent course that basically just covered this and
the decidability problem. Explaining it to a judge, who (while likely highly
intelligent) probably has no CS background, over the course of litigation is
likely to be _really_ hard.

Now, Intel certainly has enough resources to do both of these things (and they
may also have precedent to cite, that didn't exist back then or that wasn't
relevant to that case). Don't take this as an opinion on any possible result,
it's just information such as I remember it.

[1]-
[https://en.wikipedia.org/wiki/Doctrine_of_equivalents](https://en.wikipedia.org/wiki/Doctrine_of_equivalents)
[2]-
[https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis](https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis)

~~~
ouid
if it's Church Turing you're arguing, then Intel surely doesn't hold the
patent on the whole equivalence class...

~~~
amalcon
The argument is that anything with that equivalence is a processor, which
means an emulator is a processor, which means that any patent thats mentions
the word "processor" (or equivalent) covers the emulator if it would cover the
emulated device. The argument is not that the patent covers all processors.

~~~
ouid
that's not the church turing thesis then.

~~~
amalcon
You're right that it expands upon the C-T thesis a bit, so my use of the word
"literally" was incorrect. It does depend on the C-T thesis though, because it
relies on a definition of "processor" that references it. You'd still need to
explain it to a judge.

~~~
ouid
What do you mean when you say "expands upon"? Either all computers are
equivalent or you aren't invoking C-T.

------
natch
Patents expire after 17 years and x86 is 39 years old, so any of the original
patents must have expired twice over already.

They no doubt have been filing additional patents over the years. But I'm sure
MS and Qualcomm have plenty of their own patents to bargain with.

Also their warning could backfire if it gives Microsoft one more reason to
finally walk away from x86 compatibility... not that this is likely to happen
anytime soon.

~~~
aidenn0
TFA specifically mentions SSE, AVX, TSX, and SGX. All of those have had new
features added in the last year or two.

~~~
sitkack
Intel implements a thing, say SSE and AVX which were pioneered by Cray 20+
years earlier. So arguably, they took out of patent protection technology and
applied it to X86. This is exactly how the patent system was designed to work.

I would argue that what they _don 't_ get is a defacto monopoly on the use of
vector instructions for X86. Even that specific encoding. Because it is now an
issue of compatibility and interoperability. The history of closing an
instruction set from the patenting of a self few instructions is atrocious.
Millions of entities have expressed solutions to their problems in X86, having
to pay a tax to Intel in-perpetuity because of that is bullshit.

------
wfunction
Can someone explain this:

> AMD made SSE2 a mandatory part of its 64-bit AMD64 extension, which means
> that virtually every chip that's been sold over the last decade or more will
> include SSE2 support. [...] That's a problem, because the SSE family is also
> new enough—the various SSE extensions were introduced between 1999 and
> 2007—that any patents covering it will still be in force.

AMD64 requires SSE2 which was introduced in 2001, right? So isn't it just 1
year until Microsoft can put in what's required for the AMD64 architecture?

~~~
mrpippy
Worth noting that Microsoft's emulator is only emulating x86, not AMD64 (at
least not yet)

~~~
wfunction
I definitely didn't know. Are you sure about this/do you have a link?

~~~
mrpippy
Yeah, it's been mentioned in all the posts. I assume it was enough work just
to get x86 working, and there's almost no 64-bit-only Windows software
(certainly nothing you would want to run emulated).

"only 32-bit x86 support is being offered"

[http://www.anandtech.com/show/10889/microsoft-and-
qualcomm-b...](http://www.anandtech.com/show/10889/microsoft-and-qualcomm-
bring-windows-10-to-snapdragon-processors)

~~~
wfunction
Wow, you're right, I totally missed that. Thanks!!

------
faragon
Intel will not threat Microsoft, not even indirectly, in my opinion.
Rationale: once Apple starts shipping desktops and laptops with ARM chips, the
only safe port for the expensive x86 chips would be Microsoft (desktop and
server market) and big iron on Linux/Unix/Hypervisors.

------
AstralStorm
So they will ban all virtual machines which sometimes have to go for
emulation, e.g. to handle XSAVE?

Scorched earth policy will likely not be defensible under fair use law.
Reverse engineering for compatibility has a few precedents.

~~~
pgeorgi
Patents may be selectively enforced, there's no forfeiture as there is with
trademarks.

Intel had (and has) no issue with qemu or bochs emulating everything, as long
as they were niche and/or promoting the Intel platform (and grudgingly
accepting compatibles).

However a move to rid Microsoft's platform from Intel altogether without
compromising compatibility is something worth fighting for. I heard that ARM
is rather similar in that aspect: emulators for development are a-ok, but
trying to run ARM emulation on a consumer product with no ARM components
inside will drive up the legal fees until some licensing agreement is set up.

~~~
my123
Intel uses that for their x86 Android devices - and as far as I know, ARM did
not sue.

~~~
throwaway91111
Intel also makes arm processors (a cortex a5 i think?); perhaps they do
license it.

~~~
AstralStorm
Licenses can be revoked, patents cannot other than by analysis and finding
them invalid.

~~~
pgeorgi
As soon as Intel licenses the ARM ISA for each device, ARM Ltd. probably
doesn't care if it's implemented in silicon, software or expressive dance.

------
nerpderp83
Well, since x86 is a monopoly ... Intel oughta go easy on this one.

~~~
wyldfire
Intel would argue (semi-sanely) that there's no monopoly on CPUs. You can make
your own mips, arm, it even Risc-V CPUs.

Also that they cross license x86 with competitors.

~~~
pgeorgi
Were there any new licensees in the last 15 years?

Nvidia reportedly had issues getting the necessary paperwork:
[https://en.wikipedia.org/wiki/Project_Denver#History](https://en.wikipedia.org/wiki/Project_Denver#History)

~~~
amiga-workbench
How very convenient, Denver would have pooped all over Intel's Atom offerings
at the time.

------
tyingq
An earlier discussion here had most people guessing it was Apple, not
Microsoft, that Intel was lobbing the threat at.
[https://news.ycombinator.com/item?id=14518189](https://news.ycombinator.com/item?id=14518189)

~~~
Analemma_
I apologize; I did a brief search before submitting but did not see that one.

------
ikeboy
> And Intel's business health continues to have a strong dependence on
> Microsoft's business, which has to make the chip firm a little wary of
> taking the software company (or its customers) to court.

I mean, Apple and Samsung had a billion dollar lawsuit while Samsung chips
were still in iPhones. It's certainly precedented to sue a corporation you're
actively doing business with.

~~~
posterboy
They had contracts so Samsung was bound and Apple did start using their own
chips, so it's not at all certain that the law suit didn't further disturb the
business relation.

~~~
throwaway91111
I believe their chips continue to use samsung fabs today.

~~~
AstralStorm
If GlobalFoundries didn't make these chips, Intel could pick up the slack...
(Not to mention it is a consortium and not part of Samsung.)

~~~
kasabali
Intel doesnt let anyone else use their fabs.

~~~
rasz
sure they do, Intel manufactured FPGAs for a long time before buying altera

~~~
kasabali
I don't think FPGA's count in this context but I did a quick search on Intel
fabs and it looks like I'm wrong anyway:
[https://arstechnica.com/gadgets/2016/08/intel-will-allow-
arm...](https://arstechnica.com/gadgets/2016/08/intel-will-allow-arm-
chipmakers-to-use-its-10nm-manufacturing-process/)

------
pmarreck
I would personally be pleased if the millstone of the x86 instruction set sank
both Intel AND microsoft's hegemony.

------
orionblastar
I remember IBM having a contract with Intel to allow other chip companies to
make x86 chips in case Intel could not keep up with demand.

QEMU emulates X86 chips as does other emulators. I wonder how those are
effected?

~~~
matt_wulfeck
AFAIK white box emulation has been around forever. I'd be surprised if it
isn't already worked out in the courts, since this has been happening since
before computers were around.

~~~
poizan42
I don't think Intel wants to waste resources (and get bad PR) if it isn't a
significant threat to their bottom line. Microsoft saying they are going to
emulate x86 on ARM with low overhead (and thus making it possible to switch to
ARM and still use tons of legacy software) is a much bigger danger to them.

~~~
tyingq
Isn't there some notion that you have to actively defend a patent to enforce
it? That is, something where selective enforcement puts you in a weaker legal
position?

Edit: The legal term appears to be "the doctrine of latches"

~~~
CalChris
_doctrine of laches_ [1]

However, the Supreme Court has recently (March) said that laches is no defense
to patent infringement. [2]

[1]
[https://en.wikipedia.org/wiki/Laches_(equity)](https://en.wikipedia.org/wiki/Laches_\(equity\))

[2] [http://www.ipwatchdog.com/2017/03/22/supreme-court-says-
lach...](http://www.ipwatchdog.com/2017/03/22/supreme-court-says-laches-no-
defense-patent-infringement/id=79750/)

------
jonstokes
Alright, I'll come out of retirement to hit this dead horse another lick.

"if WinARM can run Wintel software but still offer lower prices, better
battery life, lower weight, or similar, Intel's dominance of the laptop space
is no longer assured."

Peter. My man. I laughed. I cried.

For the millionth time, the ARM ISA does not magically confer any sort of
performance or efficiency advantage, at least not that matters in the billion+
transistor SoC regime. (I will include some relevant links to ancient articles
of mine about magical ARM performance elves later.) ARM processors are more
power efficient because they do less work per unit time. Once they're as
performant as x86, they'll be operating in roughly the same power envelope.
(Spare the Geekbench scores... I can't even. I have ancient published rants
about that, too).

Anyway, given that all of this is the case, it is preposterous to imagine that
an ARM processor that's running emulated(!!!) x86 code will be at anything but
a serious performance/watt disadvantage over a comparable x86 part.

This brings me to another point: Transmeta didn't die because of patents.
Transmeta died because "let's run x86 in emulation" is not a long-term
business plan, for anybody. It sucks. I have ancient published rants on this
topic, too, but the nutshell is that when you run code in emulation, you have
to take up a bunch of cache space and bus bandwidth with the translated code,
and those two things are extremely important for performance. You just can't
be translating code and then stashing it in valuable close-to-the-decoder
memory and/or shuffling it around the memory hierarchy without taking a major
hit.

So to recap, x86 emulation on ARM is not a threat to Intel's performance/watt
proposition -- not even a little teensy bit in any universe where the present
laws of physics apply. To think otherwise is to believe untrue and magical
things about ISAs.

HOWEVER, x86-on-ARM via emulation could still be a threat to Intel in a world
where, despite its disadvantages, it's still Good Enough to be worth doing for
systems integrators who would love to stop propping up Intel's fat fat fat
margins and jump over to the much cheaper (i.e. non-monopoly) ARM world.
Microsoft, Apple, and pretty much anybody who's sick of paying Intel's markup
on CPUs (by which I mean, they'd rather charge the same price and pocket that
money themselves) would like to be able to say sayonara to x86.

The ARM smart device world looks mighty good, because there are a bunch of
places where you can buy ARM parts, and prices (and ARM vendor margins) are
low. It's paradise compared to x86 land, from a unit cost perspective.

Finally, I'll end on a political note. It has been an eternity since there was
a real anti-trust action taken against a major industry. Look at the amount of
consolidation across various industries that has gone totally uncontested in
the past 20 years. In our present political environment, an anti-trust action
over x86 lock-in just isn't a realistic possibility, no matter how egregious
the situation gets.

So Intel is very much in a position to fight as dirty as they need to in order
to prevent systems integrators from moving to ARM and using emulation as a
bridge. I read this blog post of theirs in that light -- they're putting
everyone on notice that the old days of antitrust fears are long gone (for
airlines, pharma, telecom... everybody, really), so they're going to move to
protect their business accordingly.

Edit: forgot the links. In previous comments on exactly this issue I've
included multiple, but here's a good one and I'll leave it at that:
[https://arstechnica.com/business/2011/02/nvidia-30-and-
the-r...](https://arstechnica.com/business/2011/02/nvidia-30-and-the-
riscification-of-x86/)

~~~
int_19h
You seem to be assuming that the scenario here is that the system will mostly
run x86 code in emulation. But it's not the case - on mobile devices, most of
the time it will run native ARM code, and most of the time that code will be
the browser. Then, of course, most apps from Windows Store will also be native
ARM. Emulation is there for that occasional desktop app that users _need_ \-
and which made Windows RT non-viable - but which they don't actually use all
the time. It's the 20% case, and if that 20% uses as much (or even more) power
as a native Intel device, that's perfectly acceptable.

~~~
jonstokes
Nope, I'm not assuming that in the slightest. In fact, I'm assuming exactly
what you're assuming -- some fraction of time way less than 50% spent running
emulated code. I'm also coming to the same conclusion you are -- that
emulation of legacy x86 code with Good Enough performance could be used as a
bridge off of x86. Reread the post.

But let me address this specifically:

"It's the 20% case, and if that 20% uses as much (or even more) power as a
native Intel device, that's perfectly acceptable."

There's no need to speculate, here: the emulated code either will use
significantly more power, or it will perform significantly worse.

In fact, as for the native ARM code on the ARM chip, it also will either use
more power or perform worse than comparable x86 code running natively on an
Intel chip within the same power envelope, because Intel has thrown a massive
amount of engineering at their microarchitectures and manufacturing process,
they have vertical integration that they can use to their advantage, and their
stuff is just very good.

Again, there are no magical ARM performance elves lurking under the hood --
the ARM ISA by itself doesn't confer any real advantages in performance (and
hence performance/watt) in the billion+ transistor regime. I truly don't
understand why this is so hard for people to accept, but I blame Apple for
spreading years of FUD about x86 (before bailing on "RISC" for it, of course).

Back to the topic of the emulated code, though: I can't say is whether
"significantly worse" or "significantly more power" will still be Good Enough,
but I'm assuming it will for most apps people care about.

~~~
jonstokes
Again, it has been over 20 years since ISA has mattered for performance in a
head-to-head matchup between comparable CPUs. Moore's Law has thoroughly done
away with it as a factor in performance. Relative code size (and cache/memory
space + bus bandwidth) of RISC vs CISC, "x86 tax" of translating into micro-ps
as a percentage of the die area, register file size, load/store, and
everything else you can think of have all fallen away as real performance
factors as transistor counts have soared and compilers have improved.

There are so many things that matter for performance now, and ARM vs. x86 ISA
just isn't anywhere on that list, and hasn't been on it for a very long time.

------
clouddrover
For anyone interested, here's a Microsoft Channel 9 video in which they talk
about some of the x86 emulation layer internals:

[https://channel9.msdn.com/Events/Build/2017/P4171](https://channel9.msdn.com/Events/Build/2017/P4171)

------
dboreham
Logically this implies that I can't execute some i386 binary that I possess
without infringing Intel patents.

I think this theory of infringement has to run into various thought-experiment
problems such as : can I auto-translate that binary into some other
instruction set, then execute the translated binary, without infringing Intel
patents? (yes, surely) Is the translator now infringing Intel patents because
it has to understand their ISA? (no, surely).

Now, can I incorporate that translator into my OS such that it can now execute
i386 binaries by translating them to my new instruction set which I can
execute either directly or by emulation? If so then I am now not infringing.
Or did infringement suddenly manifest because I combined two non-infringing
things (translator + emulator for my own translated ISA)?

~~~
comex
If you execute your i386 binary on an Intel, AMD, or other licensed processor,
then you're protected by the doctrine of exhaustion:

[https://en.wikipedia.org/wiki/Exhaustion_of_intellectual_pro...](https://en.wikipedia.org/wiki/Exhaustion_of_intellectual_property_rights)

If you execute it in an emulator, though, all bets are off...

~~~
mrpippy
Here's an insane idea--what if every Win10 ARM laptop also included a Pentium
4 or Athlon XP chip (from a junked PC) glued inside the case? Would the x86
patent rights from that chip cover an emulator running on the ARM?

(I'm pretty sure it's a no, but an Aereo-esque lawsuit arguing the opposite
would be fun to watch)

~~~
tachyonbeam
No more than wearing an Intel t-shirt would give you rights to all their
patents.

------
payne92
It will be interesting to see how this strategy fares in the US, given the
Alice ruling which made it much harder to patent methods that were purely
software.

Intel's strategy of going after other hardware companies may not translate
neatly to emulators.

------
make3
How did I not already know Microsoft had a working x86 emulator.. this is a
massive game changer for the laptop space if it's fast and reliable enough, as
afaik ARM chips are so much more power efficient for similar perf

~~~
zeta0134
There are several existing and excellent x86 emulators floating around. In the
open source space, QEMU is quite fantastic and well supported. I'm not
surprised at all that Microsoft managed to either develop one in house, or
acquire one.

x86 is an old and _very_ well understood architecture at this point. The
difficulty thus isn't in writing a working emulator, it's in figuring out
which features you can support from a business perspective without treading on
still active patents. Microsoft is one of the few companies that can probably
absorb a patent fight here and come out on top, and if they succeed, it will
counter-intuitively threaten the continued dominance of x86. Once they can
release an ARM-based version of Windows that sports backwards compatibility
(the primary missing feature that caused Windows RT to fail spectacularly)
more mobile machines will be free to use ARM chips, and software developers
will have incentives to natively support ARM targets for power efficiency
reasons.

Since Intel banks on x86 continuing to be the dominant architecture in the
desktop and laptop space, they must feel threatened by this move, so the suit
doesn't surprise me. They'll now be fighting an uphill battle. On the one
hand, Intel processors are still pretty much king in raw performance, but on
the other hand, very few consumers actually need the kind of performance that
you can only get on Intel chips anymore. A decent web browser runs on just
about anything, so an architecture shift in the consumer space is quite
plausible. Some could argue that it's already happened with tablets.

~~~
__s
The huge tech thing here is that running Windows-on-ARM you can run x86
programs which can then call into the Windows-on-ARM OS. So no need to
virtualize the OS

~~~
kasabali
Dynamic binary translation is not exactly a huge tech thing.

------
based2
[https://blogs.technet.microsoft.com/mmpc/2017/06/07/platinum...](https://blogs.technet.microsoft.com/mmpc/2017/06/07/platinum-
continues-to-evolve-find-ways-to-maintain-invisibility/)

[https://news.ycombinator.com/item?id=14515381](https://news.ycombinator.com/item?id=14515381)

------
sliken
Keep in mind the most relevant instruction set is the X86-64 instruction set
(32 bit code is not very relevant these days). The x86-64 ISA was created by
AMD, not Intel. Intel was busy trying to milk the enterprise market with the
Itanium, trying to reserve 64 bit as an enterprise feature.

~~~
netheril96
That is not true on Windows, where most software is either 32 bit only, or
both 32 and 64 bit. In fact, for many software on Windows, the 64 bit port is
considered beta versions.

~~~
cesarb
> In fact, for many software on Windows, the 64 bit port is considered beta
> versions.

That's probably due to Microsoft's choice of keeping both "int" and "long" as
32 bits while pointers increased to 64 bits, unlike everyone else which kept
"int" as 32 bits and increased "long" to 64 bits. If any part of your program
stored a pointer in a "long", it would break when the memory allocator gave
you an address above 4G. You have to carefully comb your code to change the
relevant variables to things like LONG_PTR (which isn't a "long" on 64-bit
Windows) instead.

Storing a pointer in a long is probably common in 32-bit Windows, since window
messages have a pair of parameters, WPARAM (which, despite its name, was an
"int") and LPARAM (which was a "long"); pointers are often passed in LPARAM.

~~~
int_19h
Most Windows apps don't deal directly with things line LONG_PTR and window
procs - they just use a framework, and frameworks have been updated to do this
all correctly a long time ago (this migration started in early 00s, when
Windows on IA-64 appeared).

The main reason these days is that there's simply no strong incentive to go
64-bit for most desktop software. The 2Gb memory limit is a non-issue for most
scenarios, and other than that, why bother? If you compile and test for
32-bit, it works for anyone who is still on 32-bit Windows _and_ it works for
64-bit. And recompiling for 64-bit is usually easy, but it doubles your test
matrix - so "here's a build, but there's no official support" is not an
unpopular approach.

------
narrator
Another component of Microsoft getting off Intel is that the antitrust
settlement only applied to x86 hardware, so MS getting off x86 would let them
lock down the platform and do all their dirty tricks all over again.

------
someSven
May someone please elaborate on the difference between what MS does and
emulators on Linux like Quemu and ExaGear?

~~~
comex
The difference, as it pertains to the patent issue, is nothing technical -
it's simply that Intel feels threatened by Microsoft's emulator and not by
qemu. (Though if Intel has ever redistributed qemu, there may be an additional
GPL wrinkle...)

~~~
rwmj
Intel contributes to qemu (or at least, developers with @intel.com email
addresses contribute). However AFAIK they don't contribute to the emulation
code (TCG).

------
asveikau
Another reason Microsoft should be telling ISVs to recompile for Win32 on ARM
instead of binary emulation.

------
kev009
IBM sold an x86 translation for a while
[https://en.wikipedia.org/wiki/PowerVM_Lx86](https://en.wikipedia.org/wiki/PowerVM_Lx86).
Would be interesting to know why it was discontinued.

~~~
mrpippy
That is odd. IBM bought Transitive and owns the tech (so no ongoing license
fees to pay) and I would thimk that x86 binary support for POWER would still
be a useful migration tool.

------
mental_
If AMD can implement x86 in hardware, why can't Microsoft implement it in
software?

~~~
boulos
AMD has a (non-transferable!) license to do so.

~~~
std_throwaway
I wonder if this kept AMD alive during the hard times.

x86 isn't going away for the next 10 years or longer.

~~~
indolering
Yup, Intel literally needs a competitor to keep out of hot-water with regards
to anti-trust laws.

------
chris_wot
Windows still has a HAL, makes me wonder why Microsoft don't just cut a new
HAL for the ARM.

It's quite possible I'm missing something vital here, of course.

~~~
SBArbeit
They have a HAL for ARM, this is to allow x86 programs to run on top of that
HAL. That's what Intel is attacking.

------
julian_1
Anyone know if it is an emulator, or an on-demand isa translator that operates
at runtime? I wonder what the implications are for infringement.

------
zekevermillion
I'll just sit hear eating my popcorn and waiting for a lowRISC computer I can
buy.

~~~
ZenoArrow
Can't see it happening in the next decade.

However, if you're interested in embedded hardware, you can buy a RISC-V chip
from SiFive now.

[https://www.sifive.com/#](https://www.sifive.com/#)

~~~
zekevermillion
Next decade?! That long???

~~~
ZenoArrow
Yes.

x86 is dominant for desktops/laptops. ARM is starting to make inroads with
Chromebooks and covers the low end. RISC V is starting from scratch, both in
terms of available hardware and software support. If RISC V can quickly prove
popular in the embedded space then perhaps we'd see a desktop/laptop earlier
than in a decade, but it's a competitive market.

To give a comparison, MIPS is popular in the embedded space, but how many
MIPS-based laptops have their been? Very few.

~~~
zekevermillion
but, lowRISC says they are going to crowdfund a SOC this year... let's say it
takes them 2 years to have one I can buy, I should be able to have a RISC V
based computer that can run linux within 5 years! Am I dreaming?

~~~
ZenoArrow
lowRISC are currently on v0.4 of their design, and we're already half way
through the year. I'd be very surprised if they decided to commit to building
an ASIC before they reached v1.0.

[http://www.lowrisc.org/blog/2017/06/lowrisc-0-4-milestone-
re...](http://www.lowrisc.org/blog/2017/06/lowrisc-0-4-milestone-release/)

By the way, I'm not trying to stop you dreaming, I'm hinting the fact that if
you want to speed things along you should get involved in the embedded space.
If you're waiting as a passive consumer you'll more than likely get
disappointed, but if you're actively contributing to the platform you may find
the wait more bearable as you're helping to speed it along.

------
ksec
Everything Intel have said and put forth are Hardware companies. I can't
believe anyone can be sued for software emulation of x86.

And unless Qualcomm and Microsoft are working on a Hardware assisteed X86
emulation, this warning shot may be directed at somebody else.

My guess: Apple.

------
nickpsecurity
I was just watning about fhis on anothet thread. It's not competition if it
requires compatibility with patdnt-protected ISA or microarchitectures. It's
coercion.

------
mtgx
So Intel is so scared of little ol' ARM (compare their revenues) that it's
willing to use patents to take it out of the PC market, rather than compete on
technical grounds?

Okay, got it. I'll make sure to account for that in my next CPU/device
purchase.

~~~
TazeTSchnitzel
Intel vs ARM revenue is not an apples-to-apples comparison, since the former
makes chips and the latter only licenses designs.

------
dis-sys
best outcome I can think of:

AMD licenses x86 patents to Qualcomm/MS to make x86 emulator better patent
troll proof. In return, Qualcomm and AMD team up for better ARM server based
processors. MS can sell more Windows/Windows Sever (sad).

~~~
cwyers
It's a non-transferable license.

------
syshum
Microsoft should Partner with AMD to pressure the big desktop and laptop OEM's
to stop using Intel CPU;s

I would love to see Dell, Lenovo and HP to switch exclusivly to Ryzen
processors,

And switch to the new Naples CPU in all their Server/Storage systems

