Slashdot Mirror


x86 Evolution Still Driving the Revolution

An anonymous reader writes "The x86 instruction set may be ancient, in technology terms, but that doesn't mean it's not exciting or innovative. In fact the future of x86 is looking brighter than it has in years. Geek.com has an article pointing out how at 30 years old x86 is still a moving force in technological advancement and, despite calls for change and numerous alternatives, it will still be the technology that gets us where we want to go. Quoting: 'As far as the world of the x86 goes, the future is very bright. There are so many new markets that 45nm products enable. Intel has really nailed the future with this goal. And in the future when they produce 32nm, and underclock their existing processors to allow the extremely low power requirements of cell phones and other items, then the x86 will be the power-house for our home computers, our notebooks, our cell phones, our MIDs and other unrealized devices today.'"

23 of 82 comments (clear)

  1. To rehash the same old story by Kjella · · Score: 5, Interesting

    x86 processosr aren't x86 processors, and haven't been for many years. They all decode the x86 instruction set to microops which they execute internally. The x86 instruction decoder doesn't take up any significant space, and if there really was an advantage to direct microop code, producers would have offered a "native" microop mode long ago. SSE instructions has provided a lot of the explicit parallelism without touchnig the standard x86 set. The mathematical complexity doesn't get less than an ADD or MUL anyway, so it would have been all about arranging the queue inside the CPU. So yeah, ADD and MUL survives but like in mathematics it's just the symbols, in implementation it can be done with everything from microops to an abacus.

    --
    Live today, because you never know what tomorrow brings
    1. Re:To rehash the same old story by mikael · · Score: 3, Informative

      Ars Technica has a good article on this debate

      RISC vs. CISC - the Post-RISC Era, and Bibliography

      In defence of RISC

      The majority of software written for any chip is compiled by a relatively small number of compilers, and those compilers tend to use pretty much the same subset of instructions. The UNIX portable C compiler for example used less than 30% of the Motorola 68000 instruction set.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    2. Re:To rehash the same old story by renoX · · Score: 2, Interesting

      >x86 processosr aren't x86 processors, and haven't been for many years. They all decode the x86 instruction set to microops which they execute internally.

      Wrong, even the early x86 processors were microcoded, so all the x86 CPUs have these decoding phase just with a varying amount of instruction decoded to microops or executed directly.
      All these CPU are x86 CPU, because they're *designed* to run the x86 instructions *efficiently* whatever the implementation details are, so a 80286 or Core2 Duo are both x86 CPUs but an Abacus or an Alpha aren't..

      That said I wonder how much the braindead x86 ISA design costs in terms of performance instead of a reasonable ISA like say the ARM (with the Thumb2 ISA extension it can get code density close to the x86), of course it depends on the code but I remember that the change from 8 to 16 integer registers in the migration from x86 to x86-64 could bring up to 20% improvement which is huge!

      Of course there's also design cost: the x86 ISA is so bizarre, that it's quite difficult to implement, but the payoff is huge given that x86 are nearly everwhere..
      And yes I agree with the article that it could become a serious competitor to ARM in the future (but not with the Atom).

  2. The power of competition... by Bert64 · · Score: 4, Interesting

    It just goes to show what can be achieved in an open market with multiple competitors (intel, amd, cyrix, via, idt etc), as opposed to a stifled closed market with one party or a small number of collaborators (alpha, hppa, ia64)....

    A few years ago, x86 was utter garbage compared to virtually every other architecture out there... But the size and competitiveness of the x86 compatible market has forced companies to invest lots of money in improving their products, to the point that x86 is now ahead of most if not all of it's proprietary counterparts.

    The sooner microsoft's strangle hold on the industry is broken, the better, so that the software world can start providing the benefits we got from the x86 compatible hardware market.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    1. Re:The power of competition... by moderatorrater · · Score: 3, Interesting

      The sooner microsoft's strangle hold on the industry is broken, the better It's interesting that you should say that considering everything that's going on. Ubuntu's the friendliest desktop distro to come around ever as far as most people are concerned. Apple keeps gaining market share, slowly but surely eating away at Microsoft. Vista came out and it included things that Macs and Linux have had for years, including a 3d desktop and something akin to sudo. In the desktop market, the pressure's building.

      In the server market Windows has always had must more competition, and it's not getting any smaller. Solaris has ZFS which is creating a lot of buzz; I remember when WinFS sounded cool, now it sounds like it would be an incremental upgrade in the face of the ZFS revolution. It wasn't even a year ago that the story came out about the Microsoft sysadmins who had to switch from linux to windows server and hated it, prompting microsoft to look into more configuration in text files.

      In the browser market, Microsoft has finally started seeing that they can't rely on IE6 forever, and now they've got IE7 out with IE8 in the works. They're moving closer to standards compliance, although they're taking their sweet time to do it and they're not taking a direct route. Safari's generating buzz, especially on the iphone, opera's dominating the embedded market and they're still the browser of choice for those who like to feel superior, and firefox is spreading like fire as swift as a fox! (it was a stretch, I know, but I couldn't resist)

      The point is that Microsoft is feeling the pinch. Vista came out and showed everyone that they were wounded, and now all the little guys are running up and taking bites out of their markets before Microsoft can respond. They'll come back with efforts to maintain market share, but the competition is heating up and Microsoft can't (and doesn't) ignore it any longer.
    2. Re:The power of competition... by dpilot · · Score: 4, Interesting

      > stifled closed market ... (alpha, hppa, ia64)....

      Into this thought we have to insert IA64, and I'm not sure how the heck we do. With any discussion of IA64, competition, and closed market is has to come up. IA64 was designed first and foremost to be a closed market, utterly unclonable. Though an Intel/HP joint venture, neither company owns any of the IP related to IA64. Instead the IP is owned by a separate company, and Intel and HP have a license to the IP from that company. That way, the IA64 IP is protected from any cross-licensing agreements that Intel or HP may have made, or may make in the future, since they don't have the rights to make any such agreements.

      IA64 is closed as no architecture ever has been before. But it has been practical matters preventing its widespread adoption, not the competition-proof IP bomb that is its basic nature.

      Oh yeah, IANAL.

      --
      The living have better things to do than to continue hating the dead.
    3. Re:The power of competition... by NotBornYesterday · · Score: 2, Informative

      I agree with your point about competition being good, but technically, Intel tried to keep x86 closed and proprietary. Competition from AMD and others grew despite the spec not being open.

      --
      I prefer rogues to imbeciles because they sometimes take a rest.
  3. Baloney by LizardKing · · Score: 3, Informative

    The article appears to be written from the perspective of someone who knows fuck all about the embedded market. The majority of embedded products that have something more sophisticated than an 8bit processor are using Motorola M68K, ARM or MIPS derivatives. That's likely to stay that way, as x86 processors tend to be large, comparatively power hungry and focused on high clock speeds - especially the ones from Intel and AMD. In fact, the only vaguely embedded device I've come across with an x86 chip was using a 486 clone (from Cyrix I think).

    1. Re:Baloney by LizardKing · · Score: 2, Informative

      Yup, but the authors argument that familiarity with development tools for x86 (and what seems like an assumption that those don't exist for other architectures) is going to be appealing also shows he's clueless. There are already excellent suites of tools for embedded development, in fact most of them are the same as you'd use for desktop or server development - particularly gcc, gdb and so forth targeted for your particular architecture, along with IDEs and emulators you can run on a typical PC. If the author thinks something like Visual Studio is going to appeal for embedded programming then he's even more of a nitwit.

  4. Mobile phones + x86 ... again! by bestinshow · · Score: 4, Interesting

    I think that ARM will be rather more tenacious than this guy thinks. 32nm will not be a miracle thing that somehow magically drops x86 (even Atom) down into a mobile phone friendly CPU in terms of power consumption and size (never mind the supporting chipset). Companies with years of ARM code will not suddenly decide to port to x86 on the off-chance that x86 will get more than a tiny proportion of the mobile phone market.

    ARM in a CPU costs under a dollar to license. Those ARM SoCs probably cost under $20 each, and they're tiny and have everything you need on them. Intel would have to provide a dozen Atom variants (in terms of features and size, not clock speeds and number of cores) to even gain the interest of this marketplace. That's why 3 billion ARM based cores are created every year. There's a huge variety of options available in a truly competitive market.

    1. Re:Mobile phones + x86 ... again! by ajlitt · · Score: 4, Insightful

      Right on. Besides, the mobile market is fueled by the further integration of peripherals into SOCs. Performance and power aside: if I were going to design a smartphone, I wouldn't want to go with a three-piece cpu and chipset, not to mention licensing and development for BIOS on a new platform. And that's before including special ASICs for functionality not built into the chipset (3D accel, radio interfaces, LCD & touch panel). And then I'd be stuck with one of the few vendors who make modern embedded x86 chips.

      If I go with ARM instead, I get a wide choice of SOCs from which I can pick and choose the built-in features (including the ones mentioned above). Bootloaders are generally included as part of the BSP for any given embedded OS, and if I don't like that there's always redboot or uboot (probably more too, I haven't been in the embedded world in a few years). If I don't want to use vendor A's product on revision 2 of the product, then I choose from one of the many remaining products out there, and my code ports over cleanly.

  5. Sure, but... by MostAwesomeDude · · Score: 4, Insightful

    Although it's true that we have been forced to use x86 for quite a while, and as a result have gotten quite good at using it, that doesn't mean that it is an optimal instruction set. amd64 is an ugly hack, as is PAE, and although they do work, they don't change the fact that x86 was never intended to handle 64-bit spaces.

    Consider the various POWER arches, and the ridiculously powerful ARM arch. ARM, for example, has an SIMD extension called Neon, which makes audio decoding possible at something like 15 MHz. These are very cool and potentially powerful architectures that have never been fully explored due to Microsoft's monopoly in the nineties.

    (To be fair, Microsoft couldn't have forced adoption of another arch even if they wanted to; they homogenized the market way too far.)

    --
    ~ C.
    1. Re:Sure, but... by Moridineas · · Score: 4, Interesting

      Although it's true that we have been forced to use x86 for quite a while, and as a result have gotten quite good at using it, that doesn't mean that it is an optimal instruction set. amd64 is an ugly hack, as is PAE, and although they do work, they don't change the fact that x86 was never intended to handle 64-bit spaces. The point is, who cares one iota if x86 is an "ugly" architecture. It gets the job done, and hands down beats most of the performance in what matters most of the time--speed. Saying something like "amd64 is an ugly hack" is just completely irrelevant. If you're one of the very few programmers in the world who regularly write assembly level code, you might have a valid complaint. If you're a more typical developer or an enduser, the ancestral design of your CPU couldn't be less important.
    2. Re:Sure, but... by LizardKing · · Score: 2, Insightful

      Speed comes much further down the list of priorities in most embedded applications. Size, power consumption, heat dissipation and even code size matter more - and code size is related to instruction set. Even when it comes to performance, x86 is relatively inferior compared to something like an ARM processor - it's mostly the higher clock speed and Intel's ability to build new fabs faster than anyone else that's kept them in the game.

    3. Re:Sure, but... by the_humeister · · Score: 4, Insightful

      These are very cool and potentially powerful architectures that have never been fully explored due to Microsoft's monopoly in the nineties.
      How exactly is an ISA monoculture Microsoft's fault? Microsoft did make Windows for multiple CPU architectures. Guess which ones people bought? The x86 version because the hardware is a lot less expensive. If there's any entity to blame, it's IBM, HP, DEC, Sun etc for not bringing down the prices of their architectures.
    4. Re:Sure, but... by QX-Mat · · Score: 2, Informative

      ARM, for example, has an SIMD extension called Neon, which makes audio decoding possible at something like 15 MHz. ARM is a heavily pipelined architecture with a reduced instruction set designed to perform a specific tasks like decoding. It takes a lot of silicon to allow a pipeline to decode things outside a tradition math/vector unit. Rarely is there any kind of cross over or feedback late in the execution stage making pipelines less predicable. To make things worst, they're hard to fence, which makes pipelined operations awkward to preempt.

      I don't think it's been an abuse of position (in the vertical monopolistic sense), but rather the development of a technology that created a parallel effect on the market winner/common supplier. I believe there are more benefits from using general purpose CPUs. If MS had taken the pure RISC route we'd have co-processors for everything now.

      The future will lie in complex instruction sets that are incrementally updated with very long word "feature pipelines". Transmeta had a point with VLW CPUs, but suffered because they tried to use the tech to emulate general purpose functionality, rather than have legacy fetch-decode-execute silicon to do the mundane stuff, and offload to VLW for bespoke applications.

      Your comments on PAE are spot on btw: it is an ugly hack, but so are most methods of indirect access. I can't see translation going any time soon. We do it everywhere - protected state, dynamic linking, mmio... everywhere. Unless CPU manufacturers start providing wider internal archs that aren't linked to the width of the address bus, we're not going to see that (multiplexing is expensive!!)

      Matt
    5. Re:Sure, but... by Waffle+Iron · · Score: 2, Interesting

      Even when it comes to performance, x86 is relatively inferior compared to something like an ARM processor - it's mostly the higher clock speed

      I don't believe that. I got a Compaq iPaq PDA a few years back so I could play around with it. I was excited that it had a 200MHz ARM CPU, and I was expecting that it would run with similar performance to a 200MHz Pentium.

      I loaded Linux on to the thing and compiled a few test programs. I was highly disappointed to find out that the CPU actually ran with a performance level closer to a 66MHz 486. Live and learn. Well, it turns out that that's the price you pay for having almost no cache and a single ALU with in-order execution. This CPU certainly wasn't defeated by Intel's high clock speeds.

    6. Re:Sure, but... by edwdig · · Score: 3, Interesting

      Although it's true that we have been forced to use x86 for quite a while, and as a result have gotten quite good at using it, that doesn't mean that it is an optimal instruction set. amd64 is an ugly hack, as is PAE, and although they do work, they don't change the fact that x86 was never intended to handle 64-bit spaces.

      x86 wasn't intended to handle 32 bit either. But when it made that jump, they actually cleaned things up and made the instruction set nicer. There's a lot less weird limitations on the instruction set in 32 bit mode than 16 bit mode. The jump to 64 bit mode cleaned things up even further and actually makes things rather nice. It's not an ugly hack in any way, it's actually quite elegantly done.

      PAE, yeah, that's an ugly hack, but it's really all you can do if people are demanding > 4 GB memory on a 32 bit processor. You could do things nicer if you used segmentation, but most people developed a hatred of it due to the weird way it was implemented on the 8086 and refused to consider it ever since.

    7. Re:Sure, but... by Skapare · · Score: 2, Interesting

      If all the effort that has been put into x86 had instead been put into another architecture that was cleaner to begin with, and designed specifically for being able to migrate to 64 bit, who's to say we wouldn't be even better off than we are now with the x86 ancestry?

      Sure, I agree, we've made x86 work well. But we are comparing a processor that has had a tremendous focus to a few alternatives that have had much less focus in terms of bringing them up to speed.

      There is what I refer to as "the x86 cost". The "ugly" architecture often means that people have to spend more time figuring out things in it due to the many layers of improvements that have been done. It makes life far more complicated for those that have to work at the "bare metal" level.

      One excuse often made to justify upgrading an architecture is the need for compatibility. The suggestion I made back when 64-bit was being talked about was to go with a dual processor compatibility setup, where you have both the old 32-bit processor, and an all new 64-bit processor, side-by-side in the same machine. The oldest operating systems would just ignore the new processor. New operating systems would run on the new processor and manage the old processor like a virtual machine (so you can still run the old OS at the same time). As this migration proceeds, hardware vendors would begin making the machines with the 32-bit CPU optional. Eventually, it would be gone and the space used for a 2nd 64-bit processor. There's your compatibility.

      --
      now we need to go OSS in diesel cars
    8. Re:Sure, but... by argent · · Score: 2, Informative

      Pipelines are an implementation technique, not part of an architecture. Some architectures make it easier to take advantage of pipelining than others, but that doesn't mean they're pipelined architectures. Hell, the intel x86-family processors have had longer pipelines than just about anything else for at least a decade. P4 family chips had up to 33 pipeline stages, neatly beating the profligate G5's max-23-stage pipeline.

      The Core 2 still has 14 stages in its pipeline.

      As for the ARM, the XScale has 5 stages, other arm implementations have had up to 8.

    9. Re:Sure, but... by Waffle+Iron · · Score: 2, Interesting
      The size of the x86 decoder as a percentage of die area has been decreasing ever since the days of the 386. It's now pretty negligible. In return for that, you get a very compact instruction set coding that saves on cache space, thus cutting down on the largest single consumer of real estate on the die.

      I notice that the ARM has added a whole alternative instruction set to save on code size, too. So the idea must have some merit.

  6. Re:Misspelt `inertia'. by drsmithy · · Score: 2, Interesting

    As to x86, the major software vendor's complete failure to move platforms (something which that other, different, company managed twice) [...]

    What an idiotic comparison. What would the business benefit of moving to another architecture have been ?

    (We'll ignore for a second that the "major software vendor's" product has been sold for five or six different architectures (depending on how you count) and internally ported to several others.)

  7. "revolution" by nguy · · Score: 2, Interesting

    That's "revolution" as in "spinning in place"? :-)

    Seriously, x86 these days is just a compression format for a kind of RISC processor. It's probably not a very good compression format, but that probably also doesn't make a big difference.