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.'"
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
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!
Innovation is bringing something on the market that wasn't there before. Most innovation isn't about inventions, but about tweaks to businessmodels, minor changes to productlines, or even just a revamp of the sales material.
This silly blog post looks back at x86 and only x86, fails to put it in perspective, and is otherwise not well researched. In short, a contribution in the best web 2.0 tradition.
As to x86, the major software vendor's complete failure to move platforms (something which that other, different, company managed twice), and its proposed johnny-come-lately successor is a major failure. x86-64 isn't from intel but it finds itself forced to run along with it.
Sometimes I wonder what'd happened if IBM would've done the right thing from a technical perspective and chose anything else, like the m68k or the zilog Z8000 for their PC. Much less braindamage to millions of programmers, for one.
The whole thing lives by inertia and collective mediocrity. IBM, microsoft, and intel; this is the best they could come up with?
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.
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.
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.
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
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.
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.