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.'"
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.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Things would be a lot easier if the darned thing wasn't so bloody complex to emulate. I mean if we were "stuck" with (say) an ARM or even a 68K we'd be able to use virtual machines to dig ourselves out of a similar architectural hole (though with an ARM we'd be unlikely to want to).
:-)
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...
Any sufficiently advanced technology is insufficiently documented.
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?
Sometimes I doubt your committment to SparkleMotion!
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.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
Actually the encoding is VERY efficient where it matters most, cache density and limiting the number of calls to main memory. Having complex instructions helps in the areas where real world performance is most hurt and that is why we have a CISC frontend to an efficient RISC backend. This balance was reached even in the "RISC" camp, look at the PPC970 with the more complex instructions that get broken down in uops and dispatched to execution units, very similar in many ways to how modern x86 processors work. The translation layer is less than one percent of die space and probably a much lower percent of power usage on modern x86 chips.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
One of the reasons that x86 is able to perform as well as it does is its code density, that is a measure of how small a number of instructions (and the memory you need to store them) is compared to the work they can do.
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.
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.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.