Slashdot Log In
Despite Aging Design, x86 Still in Charge
Posted by
Zonk
on Tue Apr 03, 2007 09:38 AM
from the king-of-the-hill dept.
from the king-of-the-hill dept.
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.'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
English is 700 years old (Score:4, Funny)
Re:English is 700 years old (Score:5, Informative)
Parent
Oh, the irony.. (Score:5, Funny)
Parent
Re:English is 700 years old (Score:5, Funny)
Parent
Re:English is 700 years old (Score:4, Interesting)
If I could stick with Windows 2000, I would have. Windows upgrades since then have just been eye candy.
Parent
Re:English is 700 years old (Score:4, Funny)
Parent
Give it more time (Score:5, Insightful)
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.
Parent
Re:English is 700 years old (Score:5, Insightful)
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.
Parent
I tried.. (Score:5, Funny)
Parent
Re:English is 700 years old (Score:5, Interesting)
RISC architectures don't give very good code density, so ARM have their ARM Thumb compressed instruction set, thats the way the embedded processors acheive good power efficiency, by cutting down the amount of memory traffic that instruction requests generate.
You can think of x86 as a way to compress the storage needed to contain the equivilent RISC instructions needed to perform the same work, that means that you make better use of available memory bandwidth and caches etc, your memory is vastly slower than the processor so you've got to make use of its bandwidth efficiently.
Parent
Re:English is 700 years old (Score:4, Interesting)
Each 4k page of code is compressed with whatever scheme is supported by the processor. The first byte indicates compression algorithm for the block or 0 for no compression (this byte is skipped over like a nop when executing sequentially from one block to the next). The block can't decompress to >4k, so many block will only be say 50% full. This saves on memory bandwidth even more than x86 and it is upgradable. If you want to save memory size too, each page can decompress to >4k and each jmp takes an address that is 50 bits of page address and 14 bits of offset into the decompressed page; we went to 64 bits to address data anyway not code. Then you get bandwitdth and in-core savings.
The CPU in some cases may have to fetch and decode a whole block just to run a 10-byte functions. So it could be an exceptionally bad idea, but I think compilers can learn to lay things out to minimize this (sounds like RISC...).
Parent
Re:English is 700 years old (Score:4, Interesting)
Parent
Let me guess... (Score:5, Insightful)
I'm going to go with:
Did I miss anything?
Re:Let me guess... (Score:5, Funny)
5. Profit
Parent
Re:Let me guess... (Score:5, Funny)
I think you forgot to mention installed base.
Parent
Re:Let me guess... (Score:5, Funny)
Parent
Weeellll there's also: (Score:5, Insightful)
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.)
Parent
Re:Let me guess... (Score:5, Informative)
I think 50% of the transistors on a modern cpu are cache, you could call that legacy stuff. But the 60% figure makes no sense. For the real, seldom used, legacy instructions, less time is spend on optimizing them in Microcode [wikipedia.org]. And the microcode does not take THAT much space on a cpu.
Some sources:
Cpu die picture, est 50% = cache [hexus.net]
P6 takes ~ 40% for compatibility reasons [arstechnica.com]. And as the total grows, the percentage should DECREASE, not INCREASE. If the amount grows it is for performance reasons, not compatibility reasons.
However when you count the source "XenSource Chief Technology officler" it is not surprising that backwards compatibility gets that much attention. A main reason virtualization exists is to run older platforms so they are compatible.
Parent
The X86 is a pig. (Score:3, Insightful)
The problem is that it is a bloody fast and cheap pig that runs a ton of software and has billions or trillions of dollars invested in keeping it useful. I am afraid we are stuck with it. At least the X86-64 is a little better.
Re: (Score:3, Interesting)
In this day and age of multi-core CPUs, why not have a processor with a X64 ISA core and a core with the desired architecture. Let them run in parallel like 32/64 bit compatible CPUs. Old software would run on the X64 cpu and newer software or updated versions could run on the newer core. Maybe this could provide a crutch for the PC world to modernize over time.
Re:The X86 is a pig. (Score:5, Insightful)
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).
Parent
Re:The X86 is a pig. (Score:4, Interesting)
Basically x86 isn't a perfect instruction set for today's landscape, but then again UNIX isn't a perfect operating system for today's landscape; that doesn't mean it's not still very good and we shouldn't praise those who have made it so good.
Some say plan9 has a better design than Linux, some say that PPC has a better design than x86, but apparently design isn't everything.
Lots of things could be better if we could get everyone to migrate from what they currently use, but would it be worth it in this case? I don't think so, at least not until we reach the limits that better design & hardware can do.
Parent
Re:The X86 is a pig. (Score:5, Interesting)
Parent
Re:The X86 is a pig. (Score:4, Insightful)
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.
Parent
Re:The X86 is a pig. (Score:5, Insightful)
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.
Parent
lock in (Score:5, Insightful)
Simple! (Score:5, Insightful)
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.
Re:Simple! (Score:5, Insightful)
An engine is black-box - petrol in, kinetic energy out (simply) - whereas the architecture on a processor is not.
AMD and Intel can make as many additions to x86 as they like, but if they stop supporting the existing instruction set, they'll sell nothing.
I'm sure Linux would be compiled on to a new architecture overnight, but I doubt MS would move any time soon - and their opinion holds a lot of weight on the desktop.
RISC ftw!
Parent
Re:Simple! (Score:5, Funny)
Parent
Re:Simple! (Score:5, Insightful)
I think that's the point, actually.
If we were going to start over and design the best way to extract usable power from gasoline from the ground up, we could probably do better than the 4-stroke, just like we could do better than the x86 ISA, and just like we could do better than LCDs for flat panel displays.
The problem is that, if you take an intrinsically inferior technology, and spend years upon years optimizing it, it will have such a head start that it is almost impossible for a newer, 'better', technology to compete.
Parent
Does it matter? (Score:5, Interesting)
At this point, does it matter as much? As we move on the future is clearly x86-64 which is MASSIVELY cleaned up compared to x86 and is really rather clean compared to that. Sure at this point we still boot into 8086 mode and have to switch up to x86-64 but that's not that important, it only lasts a short while.
As we move off of x86 onto -64, are things really still that bad? Memory isn't segmented, you have like 32 different registers, you don't have operands tied to registers (all add instructions must use AX or something like that) as some 16/32 bit instructions were.
Of course, we should have used a nice clean architecture like 68k from the start, but that wasn't what was in the first IBM.... and we all know how things went from there.
Re:Does it matter? (Score:4, Insightful)
Parent
Re:Does it matter? Less than it did (Score:4, Interesting)
I would add to this that ISA mattered a lot more when I wrote code in assembly language. For a clean (and simple) instruction set architecture, I fondly remember the PDP-11 [wikipedia.org]. Later on, the 680x0 offered more powerful addressing modes for less simplicity (and consistency). Compared to both, the x86 was infuriating to work with.
ISA's still mattered, but less, in my early "C" days when source-level debugging was less robust, or even to understand what the compiler was turning my code into so I could figure out where to optimize.
Today, it hardly matters at all. Looking at generated code tells me little about how the processor with multiple execution units is going to process it; it is necessary to trust the compiler and its optimization strategy. It matters even less with interpreted or JIT'd languages, where the work eventually performed by the processor is far removed from my code. Knowing what's happening at runtime involves much more important factors than the ISA.
Parent
Re:Does it matter? Less than it did (Score:5, Interesting)
What's with all this dissing of the X86?
Like you, I'm an old fart; I wrote assembler code for the PDP-8, PDP/LSI-11 and the 68k. They were ok: easy to learn and use, but I always preferred the X86.
Sure, it was harder to learn and I never got past having the blue book on my desk when I was coding but, in the end, it produced smaller, faster code. There were a number of apps I wrote for multiple platforms, so I got to compare. Also, (the same reason I love perl) you could do astounding things with side-effects.
Commercially, X86 has staying power because it was architected to scale. Variable-length instructions with lots of space in the operator range lets Intel adapt the design to any new demands. Most, if not all, of the complaints about X86 (e.g. too few registers) are just version features—yesterday's news if there's a market demand for an improvement.
Bottom line—it ain't neat, but that doesn't matter; it's programmed once and used millions of times. Programmer convenience is irrelevant.
Parent
If it ain't broke, don't fix it (Score:4, Insightful)
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.
Re: (Score:3, Funny)
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).
I hate to use a car analogy, but yeah. Cars have changed tremendously over the past 50+ years, but all in all, they're still four tires attached to two axles, with a transmission converting power from the engine to rotational energy in the axles, with a cabin on top of these axles with seats and a single driver's wheel, pedals, and control area. All of those components h
Anything 10 times better? (Score:4, Insightful)
Paul
It's hairy to emulate, too (Score:5, Interesting)
The x86 has so many modes of operation (SMM, real/protected, lots of choices for vectorizing instructions, 16/32/64 bit modes) and special cases that it's a pretty big project to get emulation working correctly (much less fast). You're pretty much stuck with a 10x reduction clock-for-clock on a host. Making an emulated environment secure is hard, too; you don't necessarily need specialized hardware here (e.g., specialized MMU mapping modes), but it helps.
And now, with transistor speeds bottoming-out, they want to go multicore and make *more* of the things, which is exactly the opposite direction that I want to go in...
This says it all for me: (Score:4, Insightful)
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...
60% of transistors used for legacy modes? (Score:5, Interesting)
Who is this guy and what is he smoking? Over half of a modern processor is cache. The instruction decoding and address decoding are a small fraction of the remainder. Where does he get the 60% from?
Re:60% of transistors used for legacy modes? (Score:5, Funny)
(Obl: 43% of people know that all statistics are made up.)
Parent
Excuse to Sell you Crap (Score:3)
2 cents,
QueenB
I think I know... (Score:5, Funny)
Parent
Legacy Support Drives It (Score:5, Interesting)
I know we all bitch about old designs, legacy support for outdated features, but, one of the things that keep people from moving from one OS to another is "existing base of installed software" and "knowledge of exisiting software". Like it or not, the major player is Microsoft. No matter how much a geek says, MS UI's suck, people are comfy with them. If alternative OS's had the same software offerings with the same UI, people would be able to move to them. The same holds true for processors.
No matter how well a processor performs, if there is no application base for it, no one is going to buy a machine with that processor. In this case, perception is reality. You walk into a software store, you see 16 rows of Windows applications, half a row of Linux, and 5 rows of Apple.
What processor family runs each of these? Guess who has moved to the dominant processor?
The only way to build a software base is to build in legacy support. Then start weening users away from the legacy features, get programmers to stop using those features (mainly those building the compilers that developers use), and move towards the more advanced features.
x86 rules for a reason. Microsoft rules for a reason. The customer is comfortable with them, and their perception is reinforced everytime they go to the store.
Being mostly compatible doesn't pay (Score:4, Insightful)
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.
Proprietary software locks us in (Score:4, Insightful)
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.
Welcome to the late 90s: ISA doesn't matter (much) (Score:4, Insightful)
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 [catb.org] instruction set or an One Instruction Set Computer [wikipedia.org] 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.
In short:x86 is the result of natural selection... (Score:5, Funny)
Why x86 is better than one might expect. (Score:5, Insightful)
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.
Not Windows or Linux per se _but_... (Score:5, Informative)
For WinNT and variants (2K, XP) I don't know how much 16bit code is in there. I've written drivers for 2K/XP and could not find a single 16bit style instruction however even NT series for x86 uses segments. FS is used for process & thread info. IIRC even AMD64 long mode implements FS & GS to make OS porting easier.
Lastly. 16bit code (instruction operating on 16bits of a 32bit register) are trivial in 32bit mode - all you have to do is preceed an instruction with 0x66 and/or 0x67 to switch a 32bit instruction to a 16bit instruction.
The problem transcends MSDOS and goes to the BIOS and boot sequence itself. Intel tried to address the with EFI but that seems to be slow gaining traction - probably because of backwards compatibility.
Parent