Slashdot Mirror
Despite Aging Design, x86 Still in Charge
An anonymous reader writes "The x86 chip architecture is still kicking, almost 30 years after it was first introduced. A News.com article looks into the reasons why we're not likely to see it phased out any time soon, and the history of a well-known instruction set architecture. 'Every time [there is a dramatic new requirement or change in the marketplace], whether it's the invention of the browser or low-cost network computers that were supposed to make PCs go away, the engineers behind x86 find a way to make it adapt to the situation. Is that a problem? Critics say x86 is saddled with the burden of supporting outdated features and software, and that improvements in energy efficiency and software development have been sacrificed to its legacy. And a comedian would say it all depends on what you think about disco.'"
I'm going to go with:
Did I miss anything?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The x86 instruction set will be retired in the same year as the QWERTY keyboard layout.
Just like the four stroke engine. It's not the best one, it can be largely enhanced and made better, but it's still here.
And just like the four stroke engine, modern engines just burn gasoline and push car forward. This is where the similarity with the original engines end.
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
Yes, the instruction set is old, but, it does still work. As a consumer, why should I have to re-invest in software that I purchased and does the job, just becuase my hardware failed, or faster hardware becomes available and I upgrade. Apple bit that one some time ago. Last year, I had an investment of $4000.00 in software when Intel came out with a significantly faster part that was dropping in price. Just by upgrading my hardware (cost $800) my invenstment improved significantly. $4800.00 did not justify the upgrade but the low cost of hardware only, did. Also, there was not learning curve involved.
You don't buy a new car just becuase the tires need replaceing (well some people do, but that is rarely the fiscally responsible thing).
If it ain't broke, it doesn't need fixing.
Athiesm is a religion like not collecting stamps is a hobby.
It has been said that people will not change unless something is preceived to be 10 times better. The problem is nothing has been perceived to be that much better, so people stay with what they know.
Paul
If a chipmaker declared its chip could run only software written past some date such as 1990 or 1995, you would see a dramatic decrease in cost and power consumption, Crosby said. The problem is that deep inside Windows is code taken from the MS-DOS operating system of the early 1980s, and that code looks for certain instructions when it boots.
Even new software might (and often does) use the so-called old instructions. If you want to completely redesign the hardware you would also have to completely rewrite the software from scratch as you would not be able to rely on previously written code and libraries. This is simply not feasible on a global scale...
09 f9 11 02 9d 74 e3 5b d8 41 56 c5 63
And since the 386 consisted of 275000 transistors while modern cpus have more than 200 millions transistors the cost/waste of backwards compability with the 386 is very little.
4. Price / performance. A segment the x86 have done well in.
:D
5. Security. Will my x86 progs be supported in 20 years? The answer: yes.
6. Availability. Hmm... Intel, I'd like to 1 000 000 CPUs. Intel: Sure thing.
7. Good will. What should we buy, Intel or PPC. PPC? What's that? Go Intel! Yes boss. (Just look how far Itanium got on Intel's name, alone.)
Already been done, didn't catch on (see Itanium).
Because there is such a massive amount of installed x86 software base that you'd be throwing away silicon. To be sure that software ran on the most systems possible, software would still be written for x86 and not the 'desired' architecture.
That being said, OSS tends to have good inroads in that you get all the source so can recompile to whatever architecture you want. However, since x86 is still the huge marketshare, other architectures get less attention. Also, all of the JIT languages (Java, C#, etc.) make transitioning easier IF you can get the frameworks ported to a stable environment on the 'desired' architecture.
The main problem is that there is *so* much legacy code in binary (EXE) format only (the source code for many of those has been literally lost) that can be directly tracked to money. There are systems that companies continue to use and have so much momentum that changing platforms would require extreme amounts of money to reverse engineer the current system - complete with quirks and oddities, rewrite, and (here is a big part that many people fail to add in) retest and revalidate, that many companies don't want to spend that kind of money to replace something that 'works'.
There's so much work/time/effort invested in x86 now that it's hard to jump off that train. AMD's x86-64 is a good approach in that you can run all the old stuff and develop on the new at the same time with few performance penalties. However, I don't know if we'll ever be able to shrug off the burden of x86.... at least not for a long time to come. It'd take something truly disruptive to divert from it (and what people are currently invisioning as quantum computing is not that disruption).
Computer manufacturers have tried making non-compatible machines. Commodore 64, VIC 20, Coleco Adam, Atari ST. They all had their place in time and their niche in the market before fading out.
Something they all had in common, though, is that they sold better than IBM's mostly-compatible PCjr. I attribute that difference to software and compatibility problems. Because of BIOS differences, a number of programs written for the PC couldn't run on the PCjr. That led to a fragmentation of shelf space at software retailers and confusion among retail customers, and led to customers avoiding the platform in favor of easier-to-understand options.
I would expect something similar to happen if Intel, AMD, or anyone else started making mostly-compatible x86 processors. It wouldn't sell unless all of the software people are used to running still worked. Sure, someone could take Transmeta's approach and emulate little-used functionality in firmware rather than continuing to implement everything in silicon, but it all pretty much needs to keep working, so why bother?
Seriously, why would anyone undertake the effort and expense needed to slim-down x86 processors when the potential gains are small and the market risk is pretty huge? No chip manufacturer wants to replace the math-challenged Pentium as the most recent mass-market processor to demonstrably not work right.
Pundits and nerds can talk all they want about why the x86 architecture should be put out to pasture, but it won't happen until a successor is available that can run Windows, OSX, and virtually all current software titles at acceptable speeds. At that seems pretty unlikely to happen on anything other than yet another generation of x86 chips.
If free software ever goes truly mainstream, and the stacks people use are free from top to bottom, lock in goes away in general. Even hardware lock in.
A couple of years ago, I was shifting some stuff around and I needed to clean off my main desktop machine, an x86 box. I installed the same linux distro on a G4 mac and just copied my home directory over. Everything was exactly the same -- my browser bookmarks and stored passwords, my email, my office docs, etc.
A lot of people take Apple's jump from PowerPC to x86 as a sign that x86 is unstoppable. But I'd argue that the comparative ease with which the migration took place shows how weak processor lock in is becoming. The shift from PPC to x86 was nothing compared to the jump from MacOS Classic to OS X.
The real reason x86 won't go away any time soon is that MS has decided that's the only thing it's going to support, and MS powers most of the computers in the world. Windows is closed, so MS's decision on this is final, and impossible to appeal.
We lose the X86 when another processor comes along that is cheaper, 10x more powerful, and runs all X86 software at the speed that the users consider to be the same as a PC. Until then we keep the X86. Simple as that. Next tech issue, please.
The bottom line is: has any other architecture enabled apps run significantly faster over multiple CPU generations at comparable costs? Nope. As other architecture fads have come and gone, but the X86 just absorbs the best ideas from each and keeps marching along.
The Instruction Set of a processor architecture with so many resources available to it doesn't really matter, so long as it isn't utterly and completely braindead. X86 isn't braindead enough to qualify... if you had an intercal instruction set or an One Instruction Set Computer it might.
You really want to do several things to get performance out of an instruction stream -- register renaming, instruction manipulation (breaking them apart or joining them together or changing them into other instructions), elimination of some bad instruction choices, and a host of other things. You would want to do these things even on a "clean" ISA like Alpha or PPC or MIPS. And if you are doing them, the x86 instruction set suddenly becomes much less of a problem. There are even advantages: the code size on x86 tends to be better than a 32-bits-per-instruction architecture.
Instruction sets are languages with exact meanings. Which means that you can precisely translate from one instruction set to another. And, as it turns out, you can do it fairly easily and efficiently. Which is why Transmeta did pretty well. Which is why Apple's rosetta and Java JIT compilers work (and Alpha FX32 before that). Which is why AMD and Intel are right there at the top of the performance curve with x86-style instruction sets, because it JUST DOESN'T MATTER THAT MUCH.
Why didn't Transmeta kick more butt? Because they didn't have the economies of scale that AMD and Intel have. Because they didn't have the design resources that AMD and intel have. Because AMD and Intel had better-tuned processes faster than TSMC or whoever was fabbing Transmeta's chips. THOSE are the most important things, not the instruction set that you have on disk.
Now a good ISA can help in many ways: SIMD instructions really help to point out data level parallelism. More registers helps a wee bit to prevent unnecessary work done around the stack for correctness. You can get rid of a bit of logic if you can execute without translation. But these things can either be added to x86 (SSE/x86-64) or aren't expensive enough to be worth it on a 100 sq mm, >50W processor. Maybe in an embedded, low-power processor.
-- Erich
Slashdot reader since 1997
> Now, this is the important part: He's used to XP. He's used to an OS, that while sucky, worked well enough for him, was relatively speedy, so why can't he just have that? Why does he have to have something replaced that worked just to put up with this shit?
If instead of giving up after a day, he had tried it for a week or a month, he would have found out how great everything is. Then in a few months he would be used to it and if you try to make him downgrade to XP he will cry.
There are many great features in Vista, but you have to try it for yourself.
I'll probably be modded down for this...
> Oh, and before I get modded into oblivion by the MS fanboys,
For gods sakes, express a point of view and STOP FUCKING WHINING ABOUT MODERATION.
Seriously. Even if you ARE modded down, it doesn't make you some kind of martyr.
Done with slashdot, done with nerds, getting a life.
Any processor has to do the exact same work, whether the user-visible encoding is done this way or as an "SP indexed" addressing mode. At the micro-op level, it all gets renamed, reordered, etc. so that the same things are happening. Moreover, that particular sequence is so common, in all probability most X86 CPUs have special logic just to optimally execute that entire sequence faster that the naive RISC equivalent.
The x86 instruction set is a surprisingly good way to build a computer. The reasons aren't obvious.
First, the original x86 was a huge pain, with that stupid segmented memory arrangement. But IA-32 was better and cleaner; at last there was a flat 32-bit address space. (Yes, there's a segmented 48-bit mode, and Linux even supports it, but at least apps see a flat address space.) AMD-64 is even more regular; the segmented memory stuff is completely gone in 64 bit mode. So there is progress.
RISC architectures could yield simple machines that could execute one simple fixed-width instruction per clock cycle. The early DEC Alphas, the MIPS machines, and early IBM Power chips are examples of straightforward RISC machines. This looked like a big win. The ALU was simple, design teams were small (one midrange MIPS CPU was designed by about six people), and debugging wasn't hard. RISC looked like the future around 1990.
What really changed everything was advanced superscalar architecture. The Pentium Pro, which could execute significantly more than one instruction per clock, changed everything. The complexity was appallingly high, far beyond that of supercomputers. The design teams required were huge; Intel peaked somewhere around 3000 people on that project. But it worked. All the clever stuff, like the "retirement unit" actually worked. Even the horrible cases, like code that stored into instructions just ahead of execution, worked. It was possible to beat the RISC machines without changing the software.
The Pentium Pro was a bit ahead of the available fab technology. It required a multi-chip module, and was expensive to make. But soon fab caught up with architecture, and the result was the Pentium II and III, which delivered this technology to the masses. Then AMD figured out how to do superscalar x86, too, using different approaches than Intel had taken.
The RISC CPUs went superscalar too. But they lost simplicity when they did. One of the big RISC ideas was to have many, many programmer-visible registers and do as much as possible register-to-register. But superscalar technology used register renaming, where the CPU has more internal registers than the programmer sees. The effect is that references to locations near the top of the stack are as efficient as register references. Once the CPU has that capability, all those programmer-visible registers don't help performance.
Making all the instructions the same size, as in most RISC machines, leads to code bloat. Look at RISC code in hex, and you'll see that the middle third of most instructions is zero. Not only does this eat up RAM, it eats up memory and cache bandwidth, which is today's scarce resource. Fixed size instructions simplify instruction decode, but that doesn't really affect performance all that much. So x86, which is a rather compact code representation, actually turns out to be useful.