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.