13 ms·
x86: Approaching 40 and still going strong
- tyingq 9y agoSo 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?
- bhouston 9y agoMy 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-declares-windows-10-arm-devices-will-run-x86-code-near-native-speed https://www.extremetech.com/computing/249292-microsoft-decla...
- ams6110 9y agoWhy would they need to emulate x86 they can just compile for ARM.
- mattnewton 9y agoThey 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.
- glhaynes 9y agoThey’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.)
- MBCook 9y agoOne 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.
- silvestrov 9y agoThere 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.
- deleted 9y ago[deleted]
- ender341341 9y agoApple 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
- daxelrod 9y agoSo 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 https://en.wikipedia.org/wiki/Mac_68k_emulator PPC -> x86: https://en.wikipedia.org/wiki/Rosetta_(software) https://en.wikipedia.org/wiki/Rosetta_(software)
- OriginalPenguin 9y agoYeah, 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.
- wolfgke 9y ago> 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.
- tyingq 9y agoApple is notoriously secretive, so you won't get the evidence you're looking for until such a device is very close to launch.
- wolfgke 9y agoOften evidence leaks beforehand for new Apple products or plans.
- Q6T46nT668w6i3m 9y agoSure, 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.
- TheCoreh 9y agoApple 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.
- 9y ago
- MBCook 9y agoDon'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.
- johncolanduoni 9y agoThat 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.
- MBCook 9y agoIt 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.
- mikeash 9y agoMy 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.
- wolfgke 9y ago> 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.
- JustSomeNobody 9y agoThis 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.
- monocasa 9y agox86-> 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.
- clouddrover 9y agoWindows 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=A_GlGglbu1U https://www.youtube.com/watch?v=oSXUDKpkbx4 https://www.youtube.com/watch?v=oSXUDKpkbx4
- cm2187 9y agoThough 32 bit apps will get rarer. They will need to have a solution for 64bit apps.
- abrowne 9y agoMaybe they think most of those can be recompiled?
- cm2187 9y agoIf the developper is convinced there is a big enough market
- prewett 9y agoMaybe 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.
- mappu 9y agoThe 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.
- shawnz 9y agoWell, 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.
- sliken 9y agoThere'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.
- pjmlp 9y agoA 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.
- glhaynes 9y agoNot 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.
- davidf18 9y agoThe 8088 was designed in Israel so interestingly the IBM PC CPU even back then was "Israeli." https://en.m.wikipedia.org/wiki/Intel_8088 https://en.m.wikipedia.org/wiki/Intel_8088
- mixmastamyk 9y agoI 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.
- vanjoe 9y agoReading the history of fixed width simd is agonizing, every generation trying to fix mistakes. You'd think they'd learn eventually.
- paulsutter 9y agoSo 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.
- wolfgke 9y ago> 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.
- api 9y agoI'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.
- nickpsecurity 9y agoNot to mention there are safe, concurrency schemes one can use that are higher abstraction than x86 hardware.
- paulsutter 9y agoCode 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.
- nickpsecurity 9y agoDoes 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.
- wolfgke 9y ago> Intel welcomes lawful competition As long as the law is in their favor...
- BuckRogers 9y agoI noticed they didn't mention AMD in there and the billion dollar payout.
- wolfgke 9y agoWhich Intel still has not paid (cf. for example https://www.pcper.com/news/General-Tech/Intel-still-hasnt-paid-AMD-12-billion-USD-anti-trust-fine https://www.pcper.com/news/General-Tech/Intel-still-hasnt-pa...). An interesting version of "lawful competition", I think...
- krallja 9y agoSearch for "Advanced Micro Devices" -- they're mentioned very briefly.
- erikj 9y agoThe death of x86 is long overdue.
- 5ilv3r 9y agoWithout microsoft, they have nothing. I for one welcome our new RISC overlords.
- emodendroket 9y agoI 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.
- cwyers 9y agoThe 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.
- MBCook 9y agoWhich 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.
- ajdlinux 9y agoBoth the Wii and the Wii U were also PowerPC, FWIW.
- ahoka 9y ago
- ohazi 9y agoWow, 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.
- nickpsecurity 9y ago"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 https://en.wikipedia.org/wiki/Transmeta
- CalChris 9y agoI 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-suit-against-transmeta- https://www.law360.com/delaware/articles/16290/intel-files-s...
- pjmlp 9y agoWhich 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.
- Laaas 9y agoIt would also have to be stabilised, because AFAIK it changes a lot.
- 9y ago
- gigatexal 9y agoI 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.
- MBCook 9y agoThe 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.
- gigatexal 9y agoI 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?
- pjmlp 9y agoThey 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.
- pcwalton 9y ago
- nickpsecurity 9y agoIt'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.
- emodendroket 9y agoAlmost none of the computer standards people actually use are ideal, so that hardly makes x86 unique.
- nickpsecurity 9y agoThe 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.
- delsarto 9y agoIntel/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
- jackyinger 9y agoWRT 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.
- deepnotderp 9y ago"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?
- MBCook 9y agoIt'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.
- andreiw 9y agoBut 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.
- nickpsecurity 9y ago"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.
- andreiw 9y agoThing 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.
- drakenot 9y agoIs it a patent violation to emulate x86?
- mark-r 9y agoAny 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.
- nickpsecurity 9y ago"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.
- yuhong 9y agoRemember 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.
- masswerk 9y agoWhy 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.)
- wolfgke 9y ago> 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).
- dredmorbius 9y agoThat's 47 years ago, not 57. F00F bug? ;-)
- wolfgke 9y ago> 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 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 https://stackoverflow.com/a/12264515/497193).
- andreiw 9y agoMan, 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...
- mark-r 9y agoInteresting 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.
- acd10j 9y agoThis seems directed at Microsoft's attempt to emulate x86 on ARM/Qualcomm chip. https://www.extremetech.com/computing/249292-microsoft-declares-windows-10-arm-devices-will-run-x86-code-near-native-speed https://www.extremetech.com/computing/249292-microsoft-decla...
- jve 9y agoMore like boasting of patents than celebrating birthday.
- vectorEQ 9y agotry parsing x86 opcodes and still say it's strong. #debuggerfrustrations :D
- faragon 9y ago"Intel carefully protects its x86 innovations, and we do not widely license others to use them."
- gkya 9y agoFunny this article contains and champions almost all tech anti-buzzwords. Patents, proprietary, etc...
- ksec 9y agoIf, 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.
- pcwalton 9y agoThat'd just be RISC-V, essentially.