I assume lawyers on both sides have already hands full of work. I imagine these huge corporations spend lots of money on legal.

http://x-r.ai/ is working on a patent attorney AI to automate a lot of patent attorney work to resolve patent disputes more quickly and cheaply.

Hope they don't violate any patents in this process.

On the other hand, maybe they could violate them left and right and let the code sort it out.

Is there a version that works? Really interested in trying it.

you can sign up for updates at http://x-r.ai & be notified when it launches. thanks.

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.

> Intel has done a lot of work

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

No.

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.

I'm a little ignorant on this, but how can you own the rights to instructions? Isn't that the same as owning the rights to an API, or the naming and operation of functions? I mean, would I be infringing if I re-implemented the C standard library, or the standard library of some language with a copyrighted spec?

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.

Patents are entirely unlike copyright in this, in that you can come up with a totally independent implementation, and still infringe the patent. The patents are very similar to audio or video codec patents - for example, they patent the process of executing a particular instruction.

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.

I read the claims of that patent, and they are all hardware claims. As in, the claims are literally in terms of registers in a CPU. I would imagine in an emulator would have data structures in memory to represent these registers, but it won't directly infringe these claims as written.

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.

Yeah, it'll depend on your jury whether they consider an emulated register to still be a register as described. However, what's super common in these sort of patents is to duplicate the same claim language several times with slight variations to cover all implementation types. If you look at claim 9, it gives a much more broad heading:

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

If you don't have a hardware implementation, you are trying to patent an abstract idea, which Alice Corp. v. CLS Bank International found to be invalid.

Nope, an abstract idea has always been invalid. Alice vs CLS Bank found that "on a computer" wasn't a sufficient inventive step to transform an abstract idea into something patentable [1]. This can be used to invalidate a claim, but won't shrink the scope of a claim to hardware only (as then, if software was the only inventive step, it would be a pure abstract idea).

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

I'm not entirely sure what you mean. Do you mean if you have a patent that includes hardware, then that patent would prevent emulating the hardware in software? Wouldn't any software patent then be possible, by the simple expedient of describing it in the patent application as running on a custom single-purpose hardware device?

If you come up with a patentable idea, you can specify its implementation in either hardware or software in the patent (or just be ambiguous). However, if your idea alone is unpatentable, you can't add "implement it in software" to make it patentable, according to Alice vs CLS. Basically, Alice vs CLS removes a certain class of software patents, but certainly not all.

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.

[1] https://www.google.com/patents/US6126544

We're not talking here about what is right, or even what is correct under the law. We're talking about what a set of lawyers think they can plausibly use to bring an infringement case and not be laughed out of court. A broad spectrum of possibilities.

Actually this sub thread is about what is right.

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

Same way you can own the rights to touch screen gestures I guess?

Sounds pretty close to owning math. I call addition!

Hmmm. So for example, a strength of X86 is that all reads and writes are synchronized by design, guaranteed by hardware. So if two threads call a write instruction, those instructions are guaranteed to happen in the order they were written in. You have no such guarantee on ARM. What's more, Intel has a patent for this.

So now, if the same algorithm is implemented in software to emulate X86 platform on ARM, how is that not infringing on the patent?

how can it possibly infringe on any kind of patent to "promise that commands are executed in order".

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.

There seems to be a lot of mingling here of the way things ought to be and the way they are.

Reminds me of a list of "copyright myths" I saw in school.

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.

Laws operating in a grotesque and unfair way is hardly confined to intellectual property law.

there is. i have no idea how things actually are.

but laws should not contradict common sense.

But they often do.

Do I smell another Oracle v. Google style bullshit lawsuit?

When it's for the matter of compatibility, are patent laws applicable?

Yes; compatibility necessities are functional rather than expressive and therefore an exception to copyright protection. But patents are about making monopolies on functionality; a compatibility exception would undermine the whole point.

Remember that Zilog had another different instructions name only to avoid legal problems with Intel and the Z80 being binary compatible with the 8080

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.

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.

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.

Immediates are a bit of a mix. mov doesn't have very nice encodings, but many instructions do: push $1 is 2 bytes, addl $2, %eax is only 3 bytes.

There's no question that x86-64 could be improved on in terms of code density.

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.

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

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.

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

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

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

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

Can you elaborate on what is meant by "optimizations leaking out"? I am not familiar with this term. Thanks.

Like, implementation details that leak out into the architecture for optimization reasons. Classic example is branch delay slots: https://en.wikipedia.org/wiki/Delay_slot.

Thanks this is very interesting.

Microsoft isn't emulating x86-64, so far this is 32-bit only.

Almost everything that you described is microarchitectural, and not tied to the ISA.

> Almost everything that you described is microarchitectural, and not tied to the ISA.

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?

strong memory ordering is a contract. There is nothing intrinsic about the ISA, or its virtues, that dictates the ordering one way or the other. It is entirely guided by what the vendor wants to support. x86's ordering is similar to TSO in SPARC, which uses a RISC like ISA. The ordering is described as a part of the ISA, but any ISA can implement a strong ordering (at the risk of performance losses) if they want to.

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.

Which thing is micro architectural?

Intel chips have been RISC-like internally for years. They have an instruction decode stage that converts x86 instructions into an internal ISA that's more RISC-ish.

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.

"x86-64 is as bloated as RISC architectures usually are without any of RISC's benefits."

Huh? I thought the whole point of a RISC ISA is to not be bloated.

Bloated in terms of instruction encoding. All instructions on RISC architectures usually have a uniform size, as opposed to CISC architectures which are usually variable length. (Tons of exceptions exist in both directions of course.)

To add, in the case of RISC-V, the base integer ISA and most of the core extensions use fixed length 32-bit encoding (RV32/64 E/IMFAD). The basic encoding, however, allows for shorter and longer instructions in 16 bit increments. There is also the compressed ISA extension that encodes a subset of IMFAD into 16 bit instructions. The per-byte dynamic code size of the compressed extension ends up being on par with x86/x64 and Thumb2.

They are necessarily - they have to to make programs run faster.

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!

The first RISC should have read CISC. It's a typo

> I'm not sure just copying someone's technology and emulating it without paying a license fee is all that great either.

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?

I don't see why Intel would ever do that, for any amount of money that Microsoft would conceivably pay.

Well there are so many boundary conditions here . As noted below it's possible that Microsoft could emulate only older technology that isn't covered by patent. Or emulate x86 technology which has weak patent protection and then use some of their own patents to sue Intel into agreeing to license.

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.