x86: Approaching 40 and still going strong | Hacker News Reader

x86: Approaching 40 and still going strong

newsroom.intel.com

153 pointsanonymfus173 comments

Intel/x86 seems to have missed pretty much every major trend but somehow manages to keep up.

At the time, Intel seemed to have pinned the 64-bit future on Itanium. Which, on paper, is a much better architecture. Of course instruction parallelism should be in the hands of the compiler -- it has so much richer information from the source-code so it can do a better job. The MMU design was very clever (self-mapped linear page tables, protection keys, TLB sharing, etc). Lots of cache, minimal core. Exposing register rotation and really interesting tracing tools. But AMD released x86/64, Intel had to copy it, and the death warrant on Itanium was signed so we never got to really explore those cool features. Just now we're getting things like more levels of page-tables and protection-key type things on x86.

Intel missed virtualisation not only in x86 (understandable given legacy) but on Itanium too, where arguably they should have thought about it during green-field development (it was closer but still had a few instructions that didn't trap properly for a hypervisor to work). The first versions of vmware -- doing binary translation of x86 code the fly, was really quite amazing at the time. Virtualisation happened despite x86, not in any way because of it. And you can pretty much trace the entire "cloud" back to that. VMX eventually got bolted on.

UEFI is ... interesting. It's better than a BIOS, but would anyone hold that up as a paragon of innovation?

I'm not so familiar with the SIMD bits of the chips, but I wouldn't be surprised if there's similar stories in that area of development.

Low power seems lost to ARM and friends. Now, with the "cloud", low power is as much a problem in the data centre as your phone. So it will be interesting to see how that plays out (and it's starting to).

x86's persistence is certainly remarkable, that's for sure

WRT Itanium and all VLIW processors for that mater, you have to compile for the microarchitecture of the processor to fully take advantage of it. Which sinks the x86 binary portability that we've all come to know and love. Which leads to the fundamental ease that ubiquity brings to working with x86 as an end user or any software dev that doesn't really care about processor internals.

It sure would be interesting to see something else challenge x86, but since ARM/Power/RISC-V are all within the same architectural tradition I doubt they will provide it. SIMD as used by GPUs is useful only when you have very structured parallelism like arithmetic on large data sets.

I think if we're going to see a challenger worth noting they'll look like they're crazy with the hard uphill battle and novel tech they will have to produce.

> WRT Itanium and all VLIW processors for that mater, you have to compile for the microarchitecture of the processor to fully take advantage of it

True of course, but Itanium did think of this and had an "abstracted" VLIW where you worked with generic instruction bundles which the hardware was then more free to pull apart in different ways underneath. I do wonder, if we'd all taken a different path, if we'd be in more of a JIT-compiled type world. who knows?

We are in a JIT world, it's just that the code is running on the IVM ("Intel Virtual machine) being interpreted by intel's microcode.

Does the Mill architecture count as looking crazy enough?

Mill isn't too crazy from what I've seen, they seem acutely aware of the pitfalls of poor cache utilization and other things which were the bane of VLIW (outside of DSP). The future holds the truth on just how much that awareness translates into performance, but at least they're thinking a bit. The thing which concerns me about the Mill is the software-managed binary incompatibility between every model. They say this is manageable but I have some doubts about it, especially about how it plays with JITs.

They say that JITs will have to link to their proprietary system library in order to work, which seems like it could be devastating for uptake.

If you're looking for innovation on vector operations (i.e. not packed SIMD or GPU-style SPMD), then RISC-V's vector extension (especially if you consider extensions to it for graphics or scientific compute or machine learning) should seem very promising. It's not technically groundbreaking (Cray did it first), but I think it has more potential than the endless treadmill of wider packed SIMD instructions (which dissipate an immense amount of power on intel's hardware), and it is amenable to more general tasks than SPMD is.

I assumed they just went for parity since they were on smaller budgets. You're saying they did something clever with a Cray reference. Could you elaborate on that?

Well, that was the subject of Krste's thesis at Berkeley:

Vector Microprocessors

https://people.eecs.berkeley.edu/~krste/thesis.html

I wasn't aware that it was his thesis, thanks for pointing that out. There's also all the work on the Xhwacha RoCC (which I knew prof. Asanović was involved with). I think it all looks very promising and makes me eager to see what comes out of SiFive with Yunsup and Krste at or near the helm.

>"It sure would be interesting to see something else challenge x86, but since ARM/Power/RISC-V are all within the same architectural tradition"

Can you elaborate on what you mean by "architectural tradition"? I am not familiar with this term. What is the commonality of all those different architectures?

There are three main conventional instruction set architectures: RISC, CISC, and VLIW.

ARM/Power/MIPS/RISC-V are all examples of a reduced instruction set architecture, RISC.

Of course, I completely misread that. I thought the OP was including the x86(which is obviously CISC) in that. Thanks.

Actually I was, CISC and RISC are both Von Neumann machines. ISA has more to do with encoding these days anyway.

Basically, despite how sophisticated the CPU of these machines becomes it is still trying to make the appearance of executing instructions in sequence.

Current x86 processors can execute many instructions in parallel under the correct conditions leading to Instructions Per Clock (IPC) greater much than one. However typical IPC hovers around 1 and some change, unless a lot of optimization effort is invested.

In order execution of an instruction sequence (or the appearance to the user of it) is the bottleneck that has led to single threaded CPU speed increases to all but disappear now that CPU frequency scaling has more or less halted.

x86 stopped being a pure CISC long time ago.

Sure, everything now reduces to microcode and micro-ops that are completely RISC but in a historical context about CPU architecture X86 is the poster child for CISC.

I think that's all the OP was getting at.

> but in a historical context about CPU architecture X86 is the poster child for CISC

Rather the DEC VAX and perhaps MC68k are poster childs of CISC. For a discussion of RISC vs. CISC see

> http://userpages.umbc.edu/~vijay/mashey.on.risc.html

or its extended version

> http://yarchive.net/comp/risc_definition.html

and look at the tables there. You will see that among the processors on the "CISC side", the Intel i486 is nearer to RISC than many other CISC architectures.

Itanium failed because writing compilers which make VLIW efficient is probably not surmountable for human minds. Donald Knuth himself said that compilers which would make it perform even sufficiently were nearly impossible to write.

With it being borderline impossible to write good VLIW compilers, most of the instruction word was full of NOPs, which meant terrible code density, which meant I$ full of NOPs. A recipe for hot, slow computers which are depressing to program for.

>"Itanium failed because writing compilers which make VLIW efficient is probably not surmountable for human minds. Donald Knuth himself said that compilers which would make it perform even sufficiently were nearly impossible to write."

Wow, might you have any links regarding Knuth commenting on VLIW optimized compilers? I would love to read more about this.

What was Intel's view on the viability of it? It seems like quite a shortcoming.

http://www.informit.com/articles/article.aspx?p=1193856

Only two apps that I use regularly use multiple cores: Excel and VirtualBox.

and your browser :)

Especially when Mozilla's Quantum hits.

Really? Firefox? I hadn't checked. I use browsers in VMs, which typically have one core, not in hosts.

I think he was getting at how browsers nowadays put each tab in their own process. So on multi core systems, your "browser" would end up running on multiple cores

Yes, I see. Cool.

One could do it mainframe style where the I/O was offloaded to one core with the rest doing compute. Those hundreds of thousands of interrupts never hit your single-CPU task. You can get a boost in performance even in your use-case.

https://en.wikipedia.org/wiki/Channel_I/O

Even some embedded SoC's are doing this now where there's a strong core and a cheap core w/ main function and I/O split among them.

Interesting. Do you have links for any specific SoC vendors that are offering this?

Freescale's Vybrids come to mind.

That was the idea behind the Wii and the WiiU too.

People called the IO processor "the real OS" because they had never seen dedicated I/O processors before.

"People called the IO processor "the real OS" because they had never seen dedicated I/O processors before."

I didn't know that. That's funny as it's the confusion I'd expect where the old wisdom of I/O processors in non-server stuff was lost for a few generations. Then, the new one sees them to wonder if it's an extra core for apps, the OS, or whatever.

I had thought of using multiple SoCs for compartmentalization, instead of VMs. Rather like a hardware version of Qubes. I was very inspired by Tinfoil Chat.[0] Using optoisolators, one could have a secure device with strictly text-only communication with other components.

But it's over my head. I lack knowledge and equipment for measuring RF leakage among SoCs. So it goes. Maybe the Qubes team will do it :)

0) https://github.com/maqp/tfc

" I was very inspired by Tinfoil Chat.[0] Using optoisolators, one could have a secure device with strictly text-only communication with other components."

Our discussions about physical and diode security on Schneier's blog were a small part of inspiration for Tinfoil Chat. Markus Ottela then showed up to discuss the design. He wisely incorporated each piece of feedback like switching from OTP to a polycipher and covert-channel mitigation at protocol level. Loved reading his regular updates he posted of the things he added. The design, not implementation, is one of the only things I'll call NSA proof for confidentiality and security but not availability. By NSA proof, I mean without TAO getting involved with really hands-on stuff.

One drawback was he didn't know system programming. So, reference implementation is in Python. People that know statically-verifiable C, Ada/SPARK, or Rust need to implement it on a minimal TCB. I'd start with a cut down OpenBSD first just because the NSA will go for 0-days in the lower layers and they have less. Make the implementation as portable on MIPS and ARM as possible so the hardware can be interchanged easily. Trimmed Linux next if drivers absolutely need it w/ Poly2 Architecture-style deletion of unnecessary code. If money comes in, implement it on a secure CPU such as CHERI w/ CHERIBSD.

That was my plan when I was talking to him. Lots of potential with TFC after it gets a proper review of protocol and implementation.

What a great read, thanks!

Not sure I agree with that but the big idea from VLIW compilers, Fisher's trace scheduling [1], works just fine for superscalar schedulers as well.

[1] https://pdfs.semanticscholar.org/5698/09af0fcbe5a42371cea8d3...

It also failed because, at least 6 years before Itanium was even released (2001), there were better, faster options available.

In 1995, the Pentium Pro featured out-of-order and speculative execution[1]. This has two main advantages over the VLIW architecture (Itanium in particular):

1) The processor can use runtime information (such as past history of branches) to speculatively execute hundreds of instructions before they are needed.

2) When a stall happens due to a cache miss, in some cases the CPU can continue to execute instructions while waiting for the stall to end. This isn't possible with VLIW because the compiler can't predict cache hits/misses, this information is only available at runtime.

These two advantages combined made Itanium much slower than the then available x86 processors.

[1]: Note that Intel didn't invent these ideas. OoO was already known in the 1970s, although it was applied to mainframe supercomputers. I'm just using Pentium Pro as an example of a similar microprocessor.

What is fun is that x86-64 ended up having CPU vendor dependent things like SYSENTER vs SYSCALL (and even SYSCALL ended up having a bunch of vendor dependent things about it too). Win10 had to add INT 2E to the 64-bit kernel for 32-bit system calls.

> Of course instruction parallelism should be in the hands of the compiler -- it has so much richer information from the source-code so it can do a better job.

This is not true. Yes, the compiler has a lot of useful information, but it does not have access to runtime information, which the CPU does.

A modern superscalar CPU with out-of-order execution can execute instructions speculatively hundreds of cycles before they are even used.

Instructions after conditional branches can be executed speculatively using branch prediction and loads can be executed before stores (even though they might access the same address!). If the processor later detects that the load was dependent on the store, it can "undo" that operation, without any of these effects ever being visible to the running program.

While you are right, the compiler should still definitely do most of the job. There's simply no reason to keep track of dependencies, etc. at run-time, instead of doing this compile-time.

Some of that information doesn't exist at compile time...

Do you have any examples of when this beats a C program compiles with `-march -O2`?

I've read about this promise of JIT optimization being able to generate optimal code on hot paths, but in practice I've never seen it work out that way. Good AOT compilers exist today and consistently generate optimized machine code.

Your C code is already executed by the CPU in a JIT optimized way because of the way the x86 architecture is implemented on the CPU. What more proof do you want?! :)

I don't exactly know what you're searching for, but I've heard of LuaJIT beating GCC, etc. in some rare cases.

I'm honestly searching for examples of a JIT beating an AOT because it had runtime information the AOT couldn't know.

How so? When the compiler generates code like add eax, eax add ebx, ebx Of course it knows that they are independent. They could then be represented in the ISA as a block of sorts.

"so we never got to really explore those cool features"

The security stuff was explored pretty well by Secure64. I've always given them credit for at least trying to build bottom-up on it with above-average results in pentesting.

https://www-ssl.intel.com/content/dam/www/public/us/en/docum...

I still believe if AMD hadn't come up with x64 extensions, I would be typing this on an Itanium laptop now.

So it failed, because Intel wasn't the only one doing x86 processors, otherwise they would have been able to push it down our throats one way or the other.

I never really got UEFI. That's a bootloader, the only thing it has to do is :

- initialize the RAM and other essential subsystems

- initialize whatever is needed to access mass storage devices

- copy X bytes from a specific location on a specified mass storage device into RAM

- set the instruction pointer on the copied data

Everything else is the OS job. Even the BIOS does too much.

Who's gonna block you from booting Linux on your Surface Book then?

You make it sound like uranium nuclear reactors vs thorium nuclear reactors. Because of the arms race, uranium ones were developed first even though they are merely a (as one HN commenter put it) local optimum. And I remember I was one of the happy guys, rooting for AMD and enjoying cheaper processors.

Was I foolish ?

Wow, what the fuck happened with their patent applications in 2014?

It's difficult to take this threatening language seriously when it's exceedingly obvious that Intel is very suddenly (and very rightfully) terrified of losing their monopoly position. It's easier than ever to recompile and switch to ARM, and people are tired of paying the Intel tax.

They should have seen this coming well before Otellini retired. Lawsuits aren't going to save them here, and Rodgers comes out looking like an asshole for trying.

"It's easier than ever to recompile and switch to ARM"

I'd say watch out for Intellectual Ventures on the Transmeta patents. There might be some still in effect that could mess with dynamic compilation or who knows what if broadly written.

https://en.wikipedia.org/wiki/Transmeta

I think Intel licensed those patents from Transmeta as part of the resolution of their lawsuit. [1] Others did as well. But for anyone else, Intellectual Ventures could be a landmine.

[1] https://www.law360.com/delaware/articles/16290/intel-files-s...

Which is one reason for the uptake of bytecode for executables on mainstream devices, following mainframe footsteps.

Even LLVM bitcode might eventually be cleaned up to make it properly architecture independent. There was a talk about it at a past LLVM days conference.

It would also have to be stabilised, because AFAIK it changes a lot.

Agreed, but in scenarios like Android and iOS/OS X, they control the version, so they could make it stable for their purposes, or automatically update the bitcode for the apps in the store.

That's a good idea, but then a tool for that would also have to be built.

> It's easier than ever to recompile and switch to ARM

Indeed, more and more software runs on CPython or Java, so some developers might not even notice!

Not to be pedantic, but…

>Launched on June 8, 1978, the 8086 powered the first IBM Personal Computer and literally changed the world.

It was the 8088 that powered the IBM PC. (Introduced on July 1, 1979, according to Wikipedia.) Very similar but with an 8-bit bus instead of the 8086’s 16-bit.

The 8088 was designed in Israel so interestingly the IBM PC CPU even back then was "Israeli." https://en.m.wikipedia.org/wiki/Intel_8088

I read something recently about the first PC (not chip) being designed in Boca Raton, FL. The reason was to get space from the suits in NY to do their thing.

Too bad I can't remember the source.

So Intel is now resorting to threats, is it a dying gasp for x86? Wow we'll all need to recompile. Thank goodness for Linux.

Article is written by the Intel General Counsel...

> Only time will tell if new attempts to emulate Intel’s x86 ISA will meet a different fate. Intel welcomes lawful competition... However, we do not welcome unlawful infringement of our patents, and we fully expect other companies to continue to respect Intel’s intellectual property rights.

> Dying gasp for x86? Wow we'll all need to recompile.

ARM uses a weak memory model. x86 has a strong one. Also code containing optimized SIMD code (e.g. via compiler intrinsics) is a lot more complicated to port.

I've ported a lot of code back and forth and I've never encountered any difficulties related to weak vs. strong memory model.

It might matter for lock-free data structures and other potentially hardware sensitive code, but it doesn't matter for 99% of code.

Not to mention there are safe, concurrency schemes one can use that are higher abstraction than x86 hardware.

Code containing optimized SIMD will be implemented on a GPU or tensor processor.

I have actually coded for 320 GFLOPS on a Broadwell, so I know how this works, and I can tell you it's a lot easier to get vastly higher performance on a GPU.

Does it get the same price/performance ratio for the Intel CPU vs the competing CPU + GPU? And what work involved for getting to that performance for common cases? I think those are the criteria we'd look at.

What's the problem with this?

Yeah, right when that future I've been hearing out for like a decade where everyone just uses an iPad for everything comes around then they are in real trouble (I imagine that will be a year or two after the Year of the Linux Desktop).

Outside of certain kinds of work, but especially as an every day sort of casual home computer? It actually works great already. And with the new stuff in iOS 11 it will be even better.

You have to try it for a while to get used to it and sort of understand how to do it since it's slightly different… But it works SURPRISINGLY well. And the amazing size/weight/battery life of an iPad as well as the cost relative to most Apple laptops makes it attractive.

Yeah, but it's become clear that the PC isn't going anywhere at this point, and why should it, given the miserable experience of trying to do real work on a tablet?

People use PCs for more than 'work'. And even when you're in 'work' for a lot of desk jobs it works just fine with the keyboard attachment.

Since I got a good iPad I really do rarely touch my Mac at home. Mostly for games that aren't on consoles.

I'm not sure why people are so hostile to iPads. For what a TON of people use computers for they are easily past 'good enough'.

I'm not hostile to iPads per se, but I think at this point we have to acknowledge that the supposed revolution where people would never buy PCs anymore because of tablets never materialized. It's another category with a somewhat narrower niche and it works great for some tasks, but not for others.

Also, phablets have eaten into some of the demand for them.

I strongly think this is the future we're heading at.

Especially with the new iOS 11 changes. I mean, the only thing keeping me from using an iPad for everyday use is I can't do any code in it.

Aside from that, everybody is already using their phones more than their desktops, and even when they do use their desktops, it's to access the slightly uglier version of Youtube on Chrome...

Probable future will be entreprise and schools using Chromiums/Windows 10 (very closed platform, but that's not a bad thing), and iPad/iPhone (or not iOS) for every other use.

> everybody is already using their phones more than their desktops, and even when they do use their desktops, it's to access the slightly uglier version of Youtube on Chrome...

Here I say: "[citation needed]". It surely is rather the complete opposite of how I use the devices (phone: about 0 hours (I don't own a bugging device with telephony functions), PC - hell a lot).

Tablet sales sputtered and people quit talking about this. They're horrible for trying to do productive work.

you forgot to quote a threat.

EDIT: I got downvoted but this is just not a threat. If someone "reminds protestors to demonstrate lawfully", then are they "threatening to call the cops and try to put them in jail"? Of course not. Not what the word threat means. Words have meanings and this one isn't this.

So who are they talking about? It sounds like a warning, and focuses on emulation style approaches. They compared to Transmeta.

Edit: Seems odd to use Transmeta as a comparison if they are talking about software os level emulation. Wasn't Transmeta's emulation all built into the chip, no os level support/software needed?

My bet is it is apple and they are looking for ARM emulation of x86 on new Mac laptops slated for next year.

Oops, they are probably referring to Microsoft/Qualcomm's announced project here: https://www.extremetech.com/computing/249292-microsoft-decla...

Why would they need to emulate x86 they can just compile for ARM.

They have to convince everyone else to as well though. There will need to be a transition period powered by emulation for third parties, similar to Rosetta from the last time they switched architectures.

They’d have had a very hard time making the PowerPC -> Intel transition without Rosetta, but I’m not sure they’re in the same position now. How many apps on the average 12” MacBook are no longer maintained or have significant asm in them? I’d guess very few. Start with the MacBook and, over time, as Ax chips become faster and more software gets an ARM64 port, transition the whole line. (Not saying I’d bet on this scenario happening, but it doesn’t seem impossible like making the move to Intel without Rosetta would have been.)

One of the important things about the Rosetta transition was that the x86 processors were DRASTICALLY faster than the G4s, especially in mobile. The difference wasn't as big on the G5 processors, but if you had an Apple laptop even after running through Rosetta the speed difference was noticeable.

If they were to switch processors and it was only (say) 10% faster, the hit from the transition layer may make it a hard sell.

Apple has been knocking it out of the park with the A-series processors though, maybe they could make a big enough difference that it would work out again.

There is another important difference: there was no GPU back then (and QuickDraw was not very suited to GPUs. OSX changed that).

Applications where CPU time was mostly drawing on screen (e.g. text editors) worked a lot better than those where most CPU time was in app code. Today the GPU and graphics code is an even larger amount of the processing.

So for a lot of apps it will not be a big problem if the emulation is a bit slow.

Apple doesn't have the same control of the app ecosystem on macOS that they do on iOS so they'ed need to maintain some compatibility system like they've done for their previous architecture migrations

So that users can run all of their existing binaries.

Both Mac processor architecture changes so far have included emulation or binary translation layers for this purpose.

68k -> PPC: https://en.wikipedia.org/wiki/Mac_68k_emulator

PPC -> x86: https://en.wikipedia.org/wiki/Rosetta_(software)

With NeXT they had "fat" binaries to handle different processors. No emulating.

That does not solve the problem of existing binaries.

Yeah, it probably is Apple.

I can't imagine Intel going to war against Microsoft, both sides have too much to lose if they start seriously fighting. It's not called the Wintel monopoly for nothing.

But if Apple were to stop buying Intel chips, and start using their own chips in their Macs, Intel could become very litigious.

> Yeah, it probably is Apple.

Did any publicly evidence appear officially or accidentally on the internet that Apple is working on such a project (for Microsoft the situation is known)? I am just a kind of person who prefers strongly to look at the evidence instead of rumors, speculations and hopes.

Apple is notoriously secretive, so you won't get the evidence you're looking for until such a device is very close to launch.

Often evidence leaks beforehand for new Apple products or plans.

Sure, but some of this can be learned from monitoring LLVM patches and discussion groups (or attending the usual conferences). It's difficult (or impossible) to keep secrets like this from their underlying communities.

Apple has three (iOS, tvOS, watchOS) of their four platforms on ARM, so LLVM patches related to OSX on ARM could probably be plausibly disguised as patches related to these platforms.

Apple did make some noise about getting rid of support for 32 bit binaries. Reading between the lines this could be because intel owns many patents related to x86. 64 bits is less of an IP nightmare because AMD created x86-64, not intel.

Don't forget they just said High Sierra (ug) will be the last version to run 32-bit software "without compromises".

In the next version they may run 64-bit clean and use emulation in some sort of Rosetta style environment for "legacy" 32-bit software.

That seems like a pretty bizarre plan to me. The 32-bit emulator is going to be way bigger than the code that handles IA-32e mode. I think it's more likely that they'll reduce the amount of system libraries for which they ship 32-bit variants and/or require separate downloads of them. That's the real cost of keeping 32-bit support, and an emulator doesn't help on that front at all.

It seems odd, but I wonder if it would be useful in some way. At that point you could buy chips that have no 32 bit mode at all. Or you could MAKE them.

Or maybe you could make ARM chips and run a Rosetta like thing to run the 64-bit code, but since 64-bit x86 is so much cleaner it's not much of a problem compared to the whole 32-bit mess.

This is all pure speculation. I thought the way they phrased things with a little odd. It may simply be that they don't intend to update any libraries in 32 bit mode so stuff will just stop working as libraries change. It may be everything's going to start going through some layer that thinks 32-bit calls into 64-bit calls thus possibly reducing performance.

I don't know… I just feel like that statement meant something interesting and I am coming up with fun guesses.

My guess is that the "compromise" will be some fugly alert that pops up when you run a 32-bit app, saying that it's degrading system performance and you should update it and be ashamed of yourself. This is what iOS currently does, so there's precedent.

> but since 64-bit x86 is so much cleaner it's not much of a problem compared to the whole 32-bit mess.

I would not call x86-64 "cleaner" than x86-32. In many senses it is much more messy than x86-32.

I remember people saying that, but I don't have experience with it myself. I'll take your word for it.

They may have been referring to the fact that 64-bit runs in 65-but only, no choice to drop into/out of 16-bit, etc.

> They may have been referring to the fact that 64-bit runs in 65-but only, no choice to drop into/out of 16-bit, etc

Even in 64 bit mode it is possible to drop into 16 bit (protected) mode (code) if one wants to. What does not work is dropping into Virtual 8086 mode.

GNU/Linux never supported 16 bit code. For Windows it would be possible in principle (and it even would IMHO sense to support this feature on 64 bit versions of Windows). On

> https://news.ycombinator.com/item?id=14246521

I wrote something about this topic. TLDR: 64 bit Windows uses 32 bit handles, which will cause problems with 16 bit applications.

But there are also people on HN who stated the opinion that while this makes implementing support for 16 bit applications on 64 bit Windows harder for Microsoft, it would have been far from impossible, thus this technical reason is a mere convenient pretense not to implement this feature.

Actually, NTVDM on 64-bit Windows is implemented as a prototype - and it works.

This reads like they caught wind of something that really scares them. I'm in the, "it's probably Apple" camp, too. Not only is Apple doing very well with it's A series chip designs, but they have a ridiculous amount of money in the bank to fight any legal fights.

x86-> ARM is waaaay more complicated than 68K->PPC or PPC->x86 because of ARM's much weaker memory model than x86.

It's borderline a non-starter.

Windows 10 on ARM (to be released later this year) includes x86 emulation to support 32-bit x86 desktop applications on ARM. I assume Intel is talking about Microsoft.

A couple of demos of Microsoft's x86 emulation. It seems to work well:

https://www.youtube.com/watch?v=A_GlGglbu1U

https://www.youtube.com/watch?v=oSXUDKpkbx4

Though 32 bit apps will get rarer. They will need to have a solution for 64bit apps.

Maybe they think most of those can be recompiled?

If the developper is convinced there is a big enough market

Maybe if Microsoft stops shipping 32-bit OSes. But if your app needs to run on 32-bit Windows, and your app isn't one that would benefit much from 64-bit, why bother releasing a 64-bit version? It's just one more build to keep track of, and one more source of bugs.

The WOW64 layer has a few caveats. For instance, filesystem virtualization means that users of your app may see different content in a "File > Open" dialog than they would in an Explorer window.

Well, I would imagine they're hoping we go straight from 32-bit Win32 to UWP which compiles for ARM automatically. I doubt anyone today is releasing 64-bit only apps, and Win 10 for ARM is almost here, so the selection of 64-bit only apps probably will never grow too large. For developers who want to avoid UWP, they can continue to compile for both 32-bit and 64-bit as we've been doing for years.

> For developers who want to avoid UWP

For those paying attention to the BUILD talks, those developers will be gently dragged into UWP thanks to Desktop Bridge, regardless how they feel about it.

New Office version for Windows 10 will be UWP only.

CP/M, MS-DOS and Win16 compatibility were eventually removed.

MS-DOS and Win16 compatibility is NOT removed in 32-bit Windows.

I was thinking about 64 bit and future hardware only.

I don't think about 32-bit Windows since I left XP.

For what it's worth, in that first video where they say the video is running "really smoothly", the video is visibly chugging (though maybe that's just due to recording).

Heh, and Android on x86 includes ARMv7 emulation to support 32b NDK apps on x86. libhoudini, written and still maintained, by Intel.

There's been several reports of a partnership between microsoft and qualcomm to make an "always on" cheap laptop running a snapdragon 835. So just like a phone is always on, can receive message at any time, and ideally the battery lasts all day. Said project would emulate x86 on the arm to allow backward compatibility.

Chromebooks are having somewhat of the opposite battle. Intel's trying to emulate arm to run android apps on chromebooks. The reports I've seen is that intel's not competing so well. Many popular android apps run better on an arm chromebook than an intel chromebook.

In both cases I think the consumer wins, competition is good, and I'd consider a new chromebook just for the hardware and then I'd install some flavor of linux on it.

A managed OS like ChromeOS makes the underlying processor irrelevant, for application developers that is, which means more competition among those the deliver CPUs to OEMs.

This seems directed at Microsoft's attempt to emulate x86 on ARM/Qualcomm chip. https://www.extremetech.com/computing/249292-microsoft-decla...

It's called First Mover advantage, monopolistic practices, lock-in, monopolistic profits, and massive investment into custom design on shrinking processes. The ISA itself isn't special. After the marketing win, they basically sustained it with volume and monopoly laws. That their big competition also played it foolish a bit did help.

Almost none of the computer standards people actually use are ideal, so that hardly makes x86 unique.

The article is about x86. That's why Im focusing on it. What is somewhat unique is how hard x86 is to run at speeds and costs markets prefer. POWER is only other in same category but x86 dominates desktops with servers easier to change over. Intel effectively has one competitor in that space that's barely making money or losing it depending on the year.

I think x86 is to processors what facebook is to social networks and any competitors seeking to eat facebooks lunch: once you hit critical mass -- consider all the applications both high and low level that have had effort into optimizing down to the assembly level, guess what more often than not the processor family was targeted: x86. So whilst I'd love ARM to compete or even the openPower initiative to take off I doubt it because the cost to switch all the legacy software won't pan out in various cost-benefit analyses.

The problem with your theory is that there are way more ARM processors in the world.

Not only that, they are striking fast at high performance. Apples top end iPad chips are close to/better than recent laptop chips at this point. And clearly Apple can do that at scale.

The x86 world is having a harder time getting more performance out of each revision, and there's enough going on on the ARM side that we could be within reach of something interesting happening. This isn't like Transmeta or the G series chips from Motorola/IBM.

I fully agree. Just when do you think games and PCs and macs or anything or firm will make the first move all in on an arch not x86?

They already started to slowly move.

On UWP applications, if written in .NET Native, the MSIL gets uploaded to the store and is AOT compiled to native code for all existing supported architectures.

Apple has LLVM bitcode, which while still having a few leaky abstractions, there are plans among LLVM devs to eventually have a more clean architecture independent version of it.

When using a .NET based engine like Unity, the processor specific bits are part of the engine itself, so the majority of developers usually don't t write native plugins themselves.

Intel sold 300-400 million chips in 2015. That year the number of ARM CPUs sold was 15 billion.

I find it hard to frame that as "ARM can't compete with Intel", especially since PCs aren't a lucrative market anymore. You want to be in mobile, IoT, etc., and Intel threw in the towel there a while ago.

I don't think anyone was saying ARM can't compete with Intel at all. ARM, can't currently, compete with Intel in the desktop and server space in the same verticals that Intel does. Show me an 18-core general purpose server grade cpu from ARM. OR a 4.4ghz 8 thread gaming cpu for desktops? My hope is that some vendor (possibly Apple) takes the ARM IP and makes a wide instruction general purpose desktop ARM cpu.

And until that happens my original point was: business software, operating systems, etc., have been written and / or optimized for the x86 platform so much so and said software is so pervasive that leaving x86 will take a revolution or a big player to push it, again maybe Apple.

ARM can win even if it doesn't have the capability to penetrate the PC market right now. As PC margins shrink more and more, Intel's situation looks more and more precarious. Gaming CPUs are only a tiny sliver of the market, and one that is not nearly as profitable as mobile.

This is great for consumers, by the way: we're long overdue for healthy competition in the CPU market. ARM is not an open architecture, so it's not ideal, but at least the various licensees compete with each other, which is an improvement over what we have with Intel.

> And until that happens my original point was: business software, operating systems, etc., have been written and / or optimized for the x86 platform so much so and said software is so pervasive that leaving x86 will take a revolution or a big player to push, again maybe Apple.

The operating systems that matter are all ported to ARM. And perhaps the most important consumer OS today--Android--has virtually no x86 penetration. In 2017, looking at the overall market, ARM has the advantage in terms of software compatibility, not x86.

I believe the move to bytecode based formats in mobile OSes and even on OS X and UWP will make this more relevant.

Using such mainframe model, makes the actual processor only relevant to the OS vendors or the developers using "down to the metal" toolchains.

Which is something that obviously weakens Intel's position.

Oh yeah I had forgotten that point. Apple developers ship bytecode to the app store right? And then when it downloads it is specific to the phone or device, I think. Yeah that would make things a lot easier to move. So if Apple ever made another arch change like they did from PowerPC to x86 this could forgo the need for the RosettaStone translation stuff.

It is still optional on the phone and tv, but it is the official way on the watch.

You bring up a good point. I think your hinting to the server space when you bring up the shrinking margins in the PC space. And the server space already has some shipping hardware so I think that's what might pose an existential threat to Intel

> Intel welcomes lawful competition

As long as the law is in their favor...

I noticed they didn't mention AMD in there and the billion dollar payout.

Which Intel still has not paid (cf. for example https://www.pcper.com/news/General-Tech/Intel-still-hasnt-pa...). An interesting version of "lawful competition", I think...

Search for "Advanced Micro Devices" -- they're mentioned very briefly.

Interesting that of all the x86 advances made over the years, they didn't mention the most important one - the move to 64 bits. Of course that was made by AMD so they can't take any credit for that.

The whole thing is a fluff piece that is best ignored.

If, we were to create a clean x86-64 without all the old baggage, how much complexity could we get rid of? Surely with many CPU in server / non PC and closed environment recompiling should be much easier.

That'd just be RISC-V, essentially.

"Intel’s dynamic x86 ISA, and Intel will maintain its vigilance to protect its innovations and investments."

You do realize that your ISA is literally one of the worst things about your processors, right Intel?

It's also the best. Without it, their processors would just be also-rans. It's the ability to run all that software that already exists that makes them more valuable than just switching to an arm chip or something else.

But that's hardly really true anymore.

A 64-bit x86 computer with UEFI and wihout a CSM, for example, has no way to boot DOS or even a 32-bit OS (which could then use v86) to support the really old legacy. You'd have to resort to using a hypervisor, but considering the practical difference in performance, you could do the dumbest possible emulation and still run those 16-bit tasks just fine.

But that's just details. For the massive scale-out farms that power today's world with solutions based on OSS components, running proprietary legacy code just doesn't matter, so the backwards compatibility is irrelevant.

"But that's hardly really true anymore."

Like hell. Just tell all Windows users they should just replace all their software on Windows/x86 with an ARM or RISC-V box. The software will not work or will run with crap performance. They'll ditch the alternative for Intel/AMD x86. The End.

The only time they move is for something new that doesn't depend on their legacy software. Also, for stuff where they can transition unlike many enterprises locked into Windows or other x86 tech.

Thing is, that's slice of computing that gets progressively smaller, and both the upcoming Win10 on ARM64 laptop devices (with the BT for x86) and E5-competitive servers with Windows will take care of this enterprise segment.

"Thing is, that's slice of computing that gets progressively smaller"

Or it mostly stays the same for those locked in with the current rate being billions a year for the companies that locked them in. Hard to tell how long it could be before they can get off. The IBM/COBOL crowd is still locked in after 30-40 years.

Of course, it will stay locked for a few. Is the IBM/COBOL crowd representative of today's compute resources? Not really. The same could be said about OS/2-powered ATMs and point of sale terminals. The fact of their continued existence doesn't prove the OS/2 is a widely deployed and growing technology.

But overall, the world has changed quite a bit. We're suddenly not in a world ruled entirely by DB2, MSSQL and Oracle, running on AIX, Windows and Solaris. The software stack has opened up, and is no longer bound to any specific platform. The few big software names don't get to decide what kit to run them all...we're approaching a world where ISA won't matter. You'll buy hardware because it fits your performance and TCO targets, not because you're locked in.

What sucks for Intel is that they've failed to identify mobile devices as the "next PC", in the sense of the disruptive potential...the PC killed boutique workstations and servers and it killed them from the bottom. Along with IoT, that's two huge opportunities missed. Itanium was a pincer attempt, but no one targets the top and succeeds... you have to start at the bottom (this is btw why Power needs to scale and price down if it hopes to grow beyond its niche).

" Is the IBM/COBOL crowd representative of today's compute resources? Not really. "

They might be in terms of getting locked-in to a proprietary vendor using proprietary language, extensions, libraries, and/or OS's that are hard to impossible to get off of. That's exactly what Wintel has been doing with enterprise software. Microsoft is still pulling in billions despite people saying other stuff would kill them for some time now. It's a combination of their market hold, lock-in, and patent suits. They're pulling $1+ billion from Android with patents despite not contributing jack to it. Oracle and SAP are still bringing in billions due to market hold and lock-in. This is a steady thing.

"What sucks for Intel is that they've failed to identify mobile devices as the "next PC", in the sense of the disruptive potential...the PC killed boutique workstations and servers and it killed them from the bottom."

That's true. That it didn't need compatibility with Intel is exactly how it killed the need for their ISA in those sectors.

"you have to start at the bottom (this is btw why Power needs to scale and price down if it hopes to grow beyond its niche)."

I agree. Great as it is, it's way too expensive. The POWER/PPC model was doing a lot better with Apple on it selling them at reasonable price. The ecosystem was better anyway with all kinds of software made for it. It had a better ROI for buyers. They need to do that again for POWER(number here) even scaling down the capabilities as the price goes down if necessary. I'd say their accelerator interconnect that can bring in stuff like FPGA's would be a winning differentiator but Intel outsmarted IBM again with the Altera acquisition. I'm expecting great things in offloading out of that if they haven't shown up already.

Also the best in terms of lock-in sure...

Man, whoever wrote this is tone-deaf...does Intel even understand, that barriers to emulating x86 might have worked in 90s and the aughts, but that it is completely irrelevant now? Does Intel understand, that considering the penetration of OSS in the cloud and enterprise data centers, the ISA just doesn't matter anymore? They have a competitive CPU implementation, but mostly in spite of the front-facing instruction set, certainly not because of...

Reading the history of fixed width simd is agonizing, every generation trying to fix mistakes. You'd think they'd learn eventually.

Why not include the Intel 8080/Datapoint 2200, which introduced the basic instruction set and architecture? This is 57 this year!

(The first Datapoint 2200 prototypes were shipped in April 1970, official introduction in Nov 1970, Pat. 224,415 filed Nov. 27, 1970. The Texas Instruments microchip implementation was announced in June 1971 and delivered during the summer. The Intel version was filed for patent in Aug 1971 and the chip presented to Datapoint/CTC in fall 1971. Intel's first assignments to the 1201 chip, which eventually became the 8008, were apparently in spring 1970 with the project temporary stopped in July. [Source: Wood, Lamont, Datapoint; Hugo House Publishers, Ltd.; Austin, TX, 2012] — So for the architecture in general it's 1970, for the microprocessor implementation 1971.)

> Why not include the Intel 8080/Datapoint 2200, which introduced the basic instruction set and architecture?

The Intel 8080 used a different instruction set (google it). The basic instruction set was introduced with the Intel 8086 and Intel 8088 and was not binary compatible with the Intel 8080. Though Intel claimed that 8080 software could easily be ported on a source level by search and replace in the assembly code.

The Zilog Z80 extended the instruction set of the Intel 8080 and defined a new assembly language for it. I heard one of the reason that Zilog invented the new assembly language was also because of intellectual property - nevertheless one can rather objectively say that Zilog's assembly language was better than Intel's. For the assembly language for the Intel 8088/8086 Intel took lots of inspirations from Zilog (google and judge for yourself - in particular compare 8080 assembly code (Intel's assembly language), Z80 assembly code and 8088/8086 assembly code).

That's 47 years ago, not 57.

F00F bug? ;-)

> That's 47 years ago, not 57.

> F00F bug? ;-)

For those who are out of the loop: https://en.wikipedia.org/wiki/Pentium_F00F_bug

Though since your parent was talking about the Intel 8086/8088 and 0x0F: There is an incompatibility 8086/8088 and newer x86 processors: On Intel 8086/8088 the opcode 0x0F was "pop cs". From 80186/80188 on, 0x0F is instead an opcode expansion prefix (cf. https://stackoverflow.com/a/12264515/497193).

HN delivers!

Thanks ;-)

"Intel carefully protects its x86 innovations, and we do not widely license others to use them."

Funny this article contains and champions almost all tech anti-buzzwords. Patents, proprietary, etc...

Is it a patent violation to emulate x86?

Any patents for x86 itself have surely expired. Why do you think they emphasized their follow-on technologies? I wonder if SSE is still protected, but they've still got SSE2, SSE3, and whatever follows that (I haven't kept track). They're making a not-so-transparent threat that any attempt to emulate anything that still has patent protection is liable to be prosecuted.

It's the old FUD technique, make it appear that there's some legal doubt about new technologies to slow the uptake.

"Any patents for x86 itself have surely expired. Why do you think they emphasized their follow-on technologies?"

It's basically equivalent if there's no alternatives in microarchitectural details that achieve the same thing without violating a patent. There's a crazy amount of patents on that stuff. So, whoever builds it needs to sell enough to pay the lawyer fees on top of the catch up fees.

Remember the priority dates of Pentium 4 SSE2 patents released in Nov 2000 are probably around 1999 at the latest for example. SSE1 itself is just a subset of SSE2 with only single precision floating point instructions BTW. That itself was released with Pentium III in Jan 1999, meaning the priority date can't be later than 1998.

The death of x86 is long overdue.

Without microsoft, they have nothing. I for one welcome our new RISC overlords.

I don't see how you figure. Macs and various consoles are also x86. It doesn't seem like they are looking at a lot of danger except in the mobile space.

The consoles were PowerPC last generation (or, well, Xbox was, PS3 was the Cell, which is Power but also... weird). They're not especially high-end x86 chips. Games have to be ported to them regardless, so it's not like portability matters. I would bet on them continuing to be x86 in the future, but if there's a viable competitor to x86 in that price/performance/heat profile range, there's nothing to keep them from switching.

Which is interesting because we are at the point where console generations may be about to disappear. Nintendo, Sony, and Microsoft all seem interested in making it so their future consoles can run the games from their current generation without modification or custom emulation.

In other words… They're about to become a PC gaming has had for 30 years.

And that makes them LESS likely to switch to a new chip instruction set.

Both the Wii and the Wii U were also PowerPC, FWIW.

Then why is the multi billion dollar cloud industry is running on x86/Linux?

More like boasting of patents than celebrating birthday.

try parsing x86 opcodes and still say it's strong. #debuggerfrustrations :D

Reply on news.ycombinator.com