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.'"
"There's no reason why they couldn't ditch 60 percent of the transistors on the chip, most of which are for legacy modes."
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. And the microcode does not take THAT much space on a cpu.
Some sources:
Cpu die picture, est 50% = cache
P6 takes ~ 40% for compatibility reasons. 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.
Modern English is about 750 years old. English is at least 1550 years old. Tradition is to trace the English presence in Britain to the quasi-historical Anglo-Saxon incursions of the mid-5th century, but migration almost certainly preceded military confrontation. The starting point for the English language (and the Old English era) is the introduction of a continuous Anglic presence to Britain. And that linguistic heritage, termed English, begins at least 1550 years ago.
Karma: Chameleon (comes and goes)
Boot loaders tend to be 16bit segment model code 8086, at least they contain enough code to get into 32bit mode. The BIOS will be 16bit legacy code, at least some anyway as a x86 PC chip still boots in Real Mode (there is a 386 embedded variant that doesn't). Windows 9x series is _RIDDLED_ with 16 bit code esp the display drivers, although many of these switch to 32bit mode ASAP the entry points are 16 bit code. Any attempt at killing off 16bit code would stop any 9X system running.
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.
Time flies like an arrow. Fruit flies like a banana.
I drive a '96 cavalier; Its not stylish, its not particulalry fast, no power windows or locks and due to some dings, its not even orthogonal anymore. But it was cheap, relatively fuel-efficient, reliable and it gets me from A to B as fast as I'm otherwise allowed. We geeks tend to pine over these sleek ISAs like MIPS or Power in much the same way that car enthusiasts wax romantic about the latest sports car. For most of us however, practicality forces us to drive more modest vehicles. Its not practical to drive a vehicle that requires some exotic fuel in the same way that its not practical to run a CPU that digests some exotic instruction set, and for the same reasons: Limited use and availability leads to higher cost-of-ownership overall. Economies of scale and past investment lead to comparatively rock-bottom prices. The PC is also bogged by something far more sinister than the x86 instruction set, namely, the PC BIOS. This is only just beginning to go away with Apple having adopted Intel's EFI firmware (OpenBIOS on their PPC systems before that) and the growing list of LinuxBIOS supported motherboards (still not ready for personal use, but getting there). Widespread EFI adoption might take place if Microsoft releases a home OS with the capability of using EFI without the BIOS compatability layer. Another point to watch for in the future is the proliferation of platforms such as the CLR (.NET) and to a lesser extent, the JVM. These sort of platforms serve as an abstraction layer between the instruction set the software is written in, and the instruction set of the hardware on which it runs. With a performance difference of 10% or so now, and that difference shrinking as the technology matures, we'll begin to see that the underlying architecture will loose its hold on being the defining element of the platform. We're already beginning to see x86 technolgy moving towards extensions to make virtualization (such as Xen) more efficient, and I suspect it will not be long before it moves to include features to make the .net platform and similar technologies run more efficently as well. If these sort of technologies eventually become the defacto target for software, we may see a future in which the CPU's sole purpose becomes to efficiently support a higher-level platform that is defined by software.
In the Embedded world, x86 does not reign - in fact, x86 is a very small portion of the embedded market. PowerPC rules, followed by ARM and 68k, this doesn't even mention smaller processing tasks run by Microcontrollers like the 8051 or PIC devices. x86 has all but been ousted where engineers are freed from the concerns of backwards compatibility and high performance is not required.