If there's one lawyer in town, they drive a Chevrolet. If there are two lawyers in town, they both drive Cadillacs.
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.
There are so many strategies and tactics and Battle maneuvers here that it's difficult to say in just one simple hacker news posting what's going to happen.
And yet vendor-lockin is not good for competition. Is the increased incentive for research investment due to patents worth more to humanity than the resulting vendor-lockin that makes it harder to switch to AMD?
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.
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.
It's still one byte longer than the equivalent AArch64 instruction, though.
There's no question that x86-64 could be improved on in terms of code density.
They listed these features 'strong memory ordering', '(no) branch delay slots', '(no) stack windows', 'good i-cache efficiency through the use of two-address code and memory operands'.
Every single one of those is a property of the ISA - the instruction set, its semantics and encoding - not the implementation.
Which do you think isn't part of the ISA?
i-cache efficiency: Again implementation specific. Efficiency is entirely a result of implementation, isn't it ?
no branch delay slot: Yes, this is a part of the ISA. My point though was that it is uncommon enough that I wouldn't call it a great virtue of x86 per se.
Huh? I thought the whole point of a RISC ISA is to not be bloated.
For example, Alpha AXP, one of the least blown up ISAs, did not provided non-word aligned loads and stores, providing word aligned loads and stores and a way to extract and/or combine bytes and subwords from/to the whole word. And it ended having separate instructions for loading and storing every subword type. The reason I stated above - to make program run faster and to make programs smaller.
The same is true for every RISC ISA I studied.
For example, MIPS includes an instruction to store a floating point number in the reg1+reg2*arg_size address. This can be split into two RISC instructions and fused at runtime in hardware, but still here it is!
Ars Technica, as always, has the details of how that has evolved over the years. Can't remember when the article in question was written, though.
> copying someone's technology and emulating it without paying a license fee
You are contradicting yourself.
Intel built an instruction set for hardware. Emulating it on an ARM would completely negate the usefulness of it. There is no copying, since the emulator is built on software. The patents concern hardware design, not software.
The whole case should be laughable. It shouldn't even be thinkable to take something like this to court. But I'm sure some layers are going to make a lot of money.
If they're anything like the Itanium ISA patents, then Intel owns the rights to the instructions themselves and their meanings. Emulation would be infringing.
How can you even patent something like that? It goes beyond software patents, as it appears to me. But again, I'm very ignorant of this.
> 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.
For example, here's Intel's (expired) patent on the CPUID instruction:
https://patents.google.com/patent/US5671435A
It claims the particular encoding of the return data. Good luck implementing CPUID in an emulator without infringing.
There is, however, the Doctrine of Equivalents. This says that if something uses different elements / components from what's in the actual claims, it could still be argued to infringe the patent if those elements perform a role equivalent to the elements in the claims. But I'm not quite sure how far that could be stretched.
"A computer system coupled to receive and respond to computer instructions from a program routine comprising"
In later patents, they got even more clever and just say a "method" rather than a "processor", and explicitly define registers as potentially being emulated in the description (search AVX2 patents if you're curious)
The USPTO certainly seems to think an ISA is patentable, and I haven't seen a court disagree yet.
[1] https://en.wikipedia.org/wiki/Alice_Corp._v._CLS_Bank_Intern...
Yes, any software patent is possible by describing it as running on a processor. See for example [1], which has the very common claim prefix of "A machine readable storage medium storing a computer program..." Alice doesn't invalidate these patents unless, by removing that text, the remainder of the claim is unpatentable.
Because software patents are still legal, there's no need to attempt to describe them as running on a custom hardware device - you just specify them as software. Specifying custom hardware would unnecessarily reduce the scope of your claim.
So now, if the same algorithm is implemented in software to emulate X86 platform on ARM, how is that not infringing on the patent?
maybe thats a difficult problem for hardware to solve. for software, thats just how software works.
maple is solving differential equations and that may have at some point been difficult to write software for. if they have a patent for that, then so be it. I start a company that hires professors who are really good at solving differential equations, and sell the results. basically what maple yields, except produced in a different way. am i infringing on the patent?
patents patent technology. not results. you cant have a patent for "a rocket that flies to the moon" in the sense that now nobody else can build rockets flying to the moon. you can have a patent for a way to store liquid oxygen in tanks to make it yield the energy required to get a rocket to the moon. patenting concepts of things you want to do is at least morally wrong.
a hardware patent should not be capable of preventing someone from writing software that does the same thing.
its like patenting a drug that cures cancer and then using that patent to prevent oncologists from curing cancer by applying chemotherapy.
but laws should not contradict common sense.
The first nine were, "you think you can do this simple thing, this reasonable thing, or have any freedom whatsoever? SCREW YOU."
The tenth claimed it was a myth that copyright levied oppressive burdens on the consumer.
Lesson: With any type of intellectual property protection, you can usually just presume it works in the most totally disgusting way imaginable.