Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield

arstechnica.com

Post reply on HN
Print view View original

81–90 of 234 posts

Re: Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield

#81

Post by prodmerc »

ue_ wrote: post #66
bitwize wrote: post #63

Earlier quoted context omitted.

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 agai…

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

Re: Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield

#83

Post by muricula »

yellowapple wrote: post #71
pcwalton wrote: post #54

Earlier quoted context omitted.

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 t…

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

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

Re: Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield

#84

Post by pcwalton »

rayiner wrote: post #62
pcwalton wrote: post #54

Earlier quoted context omitted.

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 t…

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.

Re: Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield

#85

Post by pcwalton »

yellowapple wrote: post #71
pcwalton wrote: post #54

Earlier quoted context omitted.

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 t…

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

Re: Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield

#86

Post by dpark »

rayiner wrote: post #59

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 la…

> All on non-Intel foundry processes. That was unimaginable 10 years ago.

Not really. 15 years ago, AMD was outperforming Intel at a lower price.

Re: Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield

#87

Post by kccqzy »

pcwalton wrote: post #84
rayiner wrote: post #62

Earlier quoted context omitted.

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 compatibi…

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.

Re: Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield

#88

Post by bogomipz »

rayiner wrote: post #62
pcwalton wrote: post #54

Earlier quoted context omitted.

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 t…

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.

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

Re: Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield

#89

Post by warmwaffles »

std_throwaway wrote: post #40
Deinos wrote: post #23

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 http://law.justia.com/cases/federal/district-courts/FSupp/84...

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.

Basically what happened between Intel and AMD.

Re: Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield

#90

Post by baobrien »

pcwalton wrote: post #85
yellowapple wrote: post #71

Earlier quoted context omitted.

"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.
Post reply on HN