Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield • Hacker News Board

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

#211

Post by ZenoArrow » Sun, Jun 11, 2017, 7:03 PM UTC

zekevermillion wrote: post #205

ZenoArrow wrote: post #193

Earlier quoted context omitted.

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, 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?

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

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.

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

#212

Post by kasabali » Sun, Jun 11, 2017, 7:22 PM UTC

AstralStorm wrote: post #179

throwaway91111 wrote: post #77

Earlier quoted context omitted.

I believe their chips continue to use samsung fabs today.

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

Intel doesnt let anyone else use their fabs.

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

#213

Post by kasabali » Sun, Jun 11, 2017, 8:05 PM UTC

__s wrote: post #70

zeta0134 wrote: post #19

Earlier quoted context omitted.

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…

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

Dynamic binary translation is not exactly a huge tech thing.

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

#214

Post by ak217 » Sun, Jun 11, 2017, 8:34 PM UTC

runeks wrote: post #203

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…

> Apple's A10 is shockingly close to matching Kaby Lake on performance within a similar power envelope. Do you have a source for this claim? Not saying it's wrong, I'd just appreciate seeing a real benchmark/power usage test.

Nobody has gone to the trouble of getting this done properly in public, but the closest comparison is here:

http://www.anandtech.com/show/9766/the-apple-ipad-pro-review...

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

#215

Post by dctoedt » Sun, Jun 11, 2017, 9:15 PM UTC

natch wrote: post #167

dctoedt wrote: post #27

Earlier quoted context omitted.

> Patents expire after 17 years That's under the old law. Nowadays, for patents that issue from original applications filed on or after June 8, 1995, it's 20 years from the earliest filing date upon which priority is claimed (possibly extended to account for delays in the USPTO). [0] AFAIK, most foreign countries follow the same rule — which is significant, because when one big company sues another for patent infring…

By my math, 39 years ago is prior to 1995. But yes for patents issued later than 1995, good point, thanks for the correction.

For the benefit of anyone still reading, I'll work through an example.

+ Intel released the 8086 on June 8, 1978 [0]. Tech companies typically file U.S. patent applications just before the first public disclosure of the new technology, so as to preserve any available rights under non-U.S. patent law [1]. So let's assume that Intel filed one of its 8086 patent applications on June 7, 1978.

+ Let's also assume that it took exactly two years for that patent application to be issued as a patent, on June 7, 1980. Under the transition provisions of the "new" law, that patent would have expired on the later of (i) the issue date plus 17 years, that is, June 7, 1997; or (ii) the earliest filing date plus 20 years, that is, June 7, 1998.

[0] https://www.techopedia.com/definition/20074/intel-8086

[1] http://www.grr.com/patent-protection-and-the-novelty-require...

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

#216

Post by int_19h » Sun, Jun 11, 2017, 9:40 PM UTC

jonstokes wrote: post #131

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

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.

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

#217

Post by int_19h » Sun, Jun 11, 2017, 9:46 PM UTC

cesarb wrote: post #196

netheril96 wrote: post #178

Earlier quoted context omitted.

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.

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

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.

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

#218

Post by jonstokes » Sun, Jun 11, 2017, 9:50 PM UTC

int_19h wrote: post #216

jonstokes wrote: post #131

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

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

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.

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

#219

Post by jonstokes » Sun, Jun 11, 2017, 10:13 PM UTC

jonstokes wrote: post #218

int_19h wrote: post #216

Earlier quoted context omitted.

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

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

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.

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

#220

Post by thesz » Sun, Jun 11, 2017, 10:58 PM UTC

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.

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!