Slashdot Log In
x86 Evolution Still Driving the Revolution
Posted by
kdawson
on Fri May 09, 2008 08:22 AM
from the what's-a-few-nanometers-among-friends dept.
from the what's-a-few-nanometers-among-friends dept.
An anonymous reader writes "The x86 instruction set may be ancient, in technology terms, but that doesn't mean it's not exciting or innovative. In fact the future of x86 is looking brighter than it has in years. Geek.com has an article pointing out how at 30 years old x86 is still a moving force in technological advancement and, despite calls for change and numerous alternatives, it will still be the technology that gets us where we want to go. Quoting: 'As far as the world of the x86 goes, the future is very bright. There are so many new markets that 45nm products enable. Intel has really nailed the future with this goal. And in the future when they produce 32nm, and underclock their existing processors to allow the extremely low power requirements of cell phones and other items, then the x86 will be the power-house for our home computers, our notebooks, our cell phones, our MIDs and other unrealized devices today.'"
Related Stories
Submission: The x86 evolution will lead the revolution by Anonymous Coward
[+]
Hardware: Happy Birthday! X86 Turns 30 Years Old 362 comments
javipas writes "On June 8th, 1978 Intel introduced its first 16-bit microprocessor, the 8086. Intel used then "the dawn of a new era" slogan, and they probably didn't know how certain they were. Thirty years later we've seen the evolution of PC architectures based on the x86 instruction set that has been the core of Intel, AMD or VIA processors. Legendary chips such as Intel 80386, 80486, Pentium and AMD Athlon have a great debt to that original processor, and as recently was pointed out on Slashdot, x86 evolution still leads the revolution. Happy birthday and long live x86."
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.
To rehash the same old story (Score:5, Interesting)
Re: (Score:2, Informative)
Re: (Score:2)
I respectfully disagree. An x86 processor is any processor that can execute x86 instructions. The underlying architecture (RISC vs CISC, etc.) is irrelevant.
RISC and CISC describe instruction sets though, which is what x86 IS. So x86 can't really be either RISC or CISC - it's CISC by definition. A RISC instruction set is "smaller" (though I've never seen a set mark for how small they need to be, but x86 most certainly qualifies is too long), but specifically RISC instruction sets must have fixed-length instructions. x86 uses variable length instructions and that explicitly makes it CISC.
Re:To rehash the same old story (Score:4, Informative)
RISC vs. CISC - the Post-RISC Era [arstechnica.com], and Bibliography [arstechnica.com]
In defence of RISC [embedded.com]
The majority of software written for any chip is compiled by a relatively small number of compilers, and those compilers tend to use pretty much the same subset of instructions. The UNIX portable C compiler for example used less than 30% of the Motorola 68000 instruction set.
Parent
Re: (Score:2)
Re: (Score:2)
There is really no such thing as RISC and CISC anymore. Again, I was just using tha
Re: (Score:3, Interesting)
Wrong, even the early x86 processors were microcoded, so all the x86 CPUs have these decoding phase just with a varying amount of instruction decoded to microops or executed directly.
All these CPU are x86 CPU, because they're *designed* to run the x86 instructions *efficiently* whatever the implementation details are, so a 80286 or Core2 Duo are both x8
Re: (Score:2)
That's a large part of how Transmeta was able to get such insane power reductions with their Crusoe CPUs - they offloaded the x86-to-VLIW-micro-op translation step into software, rather than do it in circuitry. That caused a performance hit but saved a LOT of power.
The power of competition... (Score:5, Interesting)
A few years ago, x86 was utter garbage compared to virtually every other architecture out there... But the size and competitiveness of the x86 compatible market has forced companies to invest lots of money in improving their products, to the point that x86 is now ahead of most if not all of it's proprietary counterparts.
The sooner microsoft's strangle hold on the industry is broken, the better, so that the software world can start providing the benefits we got from the x86 compatible hardware market.
Re:The power of competition... (Score:4, Interesting)
In the server market Windows has always had must more competition, and it's not getting any smaller. Solaris has ZFS which is creating a lot of buzz; I remember when WinFS sounded cool, now it sounds like it would be an incremental upgrade in the face of the ZFS revolution. It wasn't even a year ago that the story came out about the Microsoft sysadmins who had to switch from linux to windows server and hated it, prompting microsoft to look into more configuration in text files.
In the browser market, Microsoft has finally started seeing that they can't rely on IE6 forever, and now they've got IE7 out with IE8 in the works. They're moving closer to standards compliance, although they're taking their sweet time to do it and they're not taking a direct route. Safari's generating buzz, especially on the iphone, opera's dominating the embedded market and they're still the browser of choice for those who like to feel superior, and firefox is spreading like fire as swift as a fox! (it was a stretch, I know, but I couldn't resist)
The point is that Microsoft is feeling the pinch. Vista came out and showed everyone that they were wounded, and now all the little guys are running up and taking bites out of their markets before Microsoft can respond. They'll come back with efforts to maintain market share, but the competition is heating up and Microsoft can't (and doesn't) ignore it any longer.
Parent
Re: (Score:2)
Re:The power of competition... (Score:5, Interesting)
Into this thought we have to insert IA64, and I'm not sure how the heck we do. With any discussion of IA64, competition, and closed market is has to come up. IA64 was designed first and foremost to be a closed market, utterly unclonable. Though an Intel/HP joint venture, neither company owns any of the IP related to IA64. Instead the IP is owned by a separate company, and Intel and HP have a license to the IP from that company. That way, the IA64 IP is protected from any cross-licensing agreements that Intel or HP may have made, or may make in the future, since they don't have the rights to make any such agreements.
IA64 is closed as no architecture ever has been before. But it has been practical matters preventing its widespread adoption, not the competition-proof IP bomb that is its basic nature.
Oh yeah, IANAL.
Parent
Re: (Score:2, Informative)
Baloney (Score:4, Informative)
The article appears to be written from the perspective of someone who knows fuck all about the embedded market. The majority of embedded products that have something more sophisticated than an 8bit processor are using Motorola M68K, ARM or MIPS derivatives. That's likely to stay that way, as x86 processors tend to be large, comparatively power hungry and focused on high clock speeds - especially the ones from Intel and AMD. In fact, the only vaguely embedded device I've come across with an x86 chip was using a 486 clone (from Cyrix I think).
Re: (Score:2)
Re: (Score:3, Informative)
Yup, but the authors argument that familiarity with development tools for x86 (and what seems like an assumption that those don't exist for other architectures) is going to be appealing also shows he's clueless. There are already excellent suites of tools for embedded development, in fact most of them are the same as you'd use for desktop or server development - particularly gcc, gdb and so forth targeted for your particular architecture, along with IDEs and emulators you can run on a typical PC. If the aut
Re: (Score:2)
And if you need new chips for that, why use x86 for those when you can use ARM?
Re: (Score:2)
Re: (Score:2)
I'm currently designing a system using one to monitor weather + soil conditions in my garden.
Still driving the revolution (Score:2)
Mobile phones + x86 ... again! (Score:5, Interesting)
ARM in a CPU costs under a dollar to license. Those ARM SoCs probably cost under $20 each, and they're tiny and have everything you need on them. Intel would have to provide a dozen Atom variants (in terms of features and size, not clock speeds and number of cores) to even gain the interest of this marketplace. That's why 3 billion ARM based cores are created every year. There's a huge variety of options available in a truly competitive market.
Re: (Score:2)
They said the same things about Apple and moto chips.
Of course, in that case, there was a single controlling power that told people how it would be. There's no "Steve Jobs" of the embedded market.
Re: (Score:2)
They said the same things about Apple and moto chips.
Yes, but the article discusses processors for embedded devices. What do you think's inside an iPod or iPhone? An ARM processor.
Re: (Score:2)
Re: (Score:2)
Writing an emulation layer is fine if you're Apple
Actually they pretty much just bought Rosetta from whichever company independently made it. Also if I can add my two cents on the subject, I think ARM pretty much won the embedded market. Maybe not forever, and maybe it has some serious concurrence out there, but I don't think anyone has to worry about their dominant position for a while.
Re:Mobile phones + x86 ... again! (Score:5, Insightful)
If I go with ARM instead, I get a wide choice of SOCs from which I can pick and choose the built-in features (including the ones mentioned above). Bootloaders are generally included as part of the BSP for any given embedded OS, and if I don't like that there's always redboot or uboot (probably more too, I haven't been in the embedded world in a few years). If I don't want to use vendor A's product on revision 2 of the product, then I choose from one of the many remaining products out there, and my code ports over cleanly.
Parent
Re: (Score:2)
Not sure whether it counts as a laptop, but despite the size the Sharp Zaurus CL3200 had all the features of one and used an ARM processor. As for desktops, the Archimedes had an ARM processor (in fact the processor was invented for it) and was an amazing machine in its day. Nowadays, you can get an ARM based desktop machine from Iyonix [iyonix.com] but they're a very niche product.
Sure there are (Score:2)
http://en.wikipedia.org/wiki/Iyonix_PC [wikipedia.org]
Sure, but... (Score:5, Insightful)
Consider the various POWER arches, and the ridiculously powerful ARM arch. ARM, for example, has an SIMD extension called Neon, which makes audio decoding possible at something like 15 MHz. These are very cool and potentially powerful architectures that have never been fully explored due to Microsoft's monopoly in the nineties.
(To be fair, Microsoft couldn't have forced adoption of another arch even if they wanted to; they homogenized the market way too far.)
Re:Sure, but... (Score:5, Interesting)
Parent
Re: (Score:3, Insightful)
Speed comes much further down the list of priorities in most embedded applications. Size, power consumption, heat dissipation and even code size matter more - and code size is related to instruction set. Even when it comes to performance, x86 is relatively inferior compared to something like an ARM processor - it's mostly the higher clock speed and Intel's ability to build new fabs faster than anyone else that's kept them in the game.
Re: (Score:2)
No doubt some/many embedded devices benefit greatly from non-x86. X86 is very steadily improving. Part of this is for sure because of Intel+AMD research divisions and fabs. What I'm saying is, the "why" is irrelevant.
How can you say that x86 is relatively inferior when compared to ARM, performancewise? Show me
Re: (Score:3, Interesting)
Even when it comes to performance, x86 is relatively inferior compared to something like an ARM processor - it's mostly the higher clock speed
I don't believe that. I got a Compaq iPaq PDA a few years back so I could play around with it. I was excited that it had a 200MHz ARM CPU, and I was expecting that it would run with similar performance to a 200MHz Pentium.
I loaded Linux on to the thing and compiled a few test programs. I was highly disappointed to find out that the CPU actually ran with a performance level closer to a 66MHz 486. Live and learn. Well, it turns out that that's the price you pay for having almost no cache and a single ALU
Re: (Score:2)
The 200MHz Pentium would be roughly four or five times of the ARM found in an iPaq, so something had to give - and that was the cache and some complexity. The ARM chip also ran much cooler and with lower power consumption than the Pentium, which needed a fan and sizable heat sink. My point about an x86 processor being inferior is that it's crippled by the instruction set, which requires a lot of decoding before the RISC-like core can actually do its work. There are diagrams that show how much real estate on
Re: (Score:2)
Re: (Score:3, Interesting)
I notice that the ARM has added a whole alternative instruction set to save on code size, too. So the idea must have some merit.
Re: (Score:3, Interesting)
If all the effort that has been put into x86 had instead been put into another architecture that was cleaner to begin with, and designed specifically for being able to migrate to 64 bit, who's to say we wouldn't be even better off than we are now with the x86 ancestry?
Sure, I agree, we've made x86 work well. But we are comparing a processor that has had a tremendous focus to a few alternatives that have had much less focus in terms of bringing them up to speed.
There is what I refer to as "the x86 cost".
Re: (Score:2)
If all the effort that has been put into x86 had instead been put into another architecture that was cleaner to begin with, and designed specifically for being able to migrate to 64 bit, who's to say we wouldn't be even better off than we are now with the x86 ancestry?
This is very possible. We've certainly seen some promising architectures that have either fizzled due to market share or scaleability. On the other hand, a lot of design from scratch to be clean and forward looking architectures have never left the starting pad virtually (Think itanium). And then there's x86 which has been consistently cheap, and is consistently able to scale. Can we really be doing that much better than x86? I'm not sure.
And on the other hand, as I mentioned in other post, the hybrid desi
Re:Sure, but... (Score:5, Insightful)
Parent
Re: (Score:2)
What, a specialized processor is able to do a task in less cycles than a more general processor? You must be joking!
The instruction set doesn't dictate how the hardware is built. I could design an ARM processor completely unsuitable for audio decoding which needs 1 Ghz to do it in real time. Does that mean the ARM instruction set sucks? No, it just means that my glorious processor is not design
Re: (Score:3, Informative)
ARM, for example, has an SIMD extension called Neon, which makes audio decoding possible at something like 15 MHz.
ARM is a heavily pipelined architecture with a reduced instruction set designed to perform a specific tasks like decoding. It takes a lot of silicon to allow a pipeline to decode things outside a tradition math/vector unit. Rarely is there any kind of cross over or feedback late in the execution stage making pipelines less predicable. To make things worst, they're hard to fence, which makes pipelined operations awkward to preempt.
I don't think it's been an abuse of position (in the vertical monopolistic se
Re: (Score:3, Informative)
The Core 2 still has 14 stages in its pipeline.
As for the ARM, the XScale has 5 stages
Re:Sure, but... (Score:4, Interesting)
x86 wasn't intended to handle 32 bit either. But when it made that jump, they actually cleaned things up and made the instruction set nicer. There's a lot less weird limitations on the instruction set in 32 bit mode than 16 bit mode. The jump to 64 bit mode cleaned things up even further and actually makes things rather nice. It's not an ugly hack in any way, it's actually quite elegantly done.
PAE, yeah, that's an ugly hack, but it's really all you can do if people are demanding > 4 GB memory on a 32 bit processor. You could do things nicer if you used segmentation, but most people developed a hatred of it due to the weird way it was implemented on the 8086 and refused to consider it ever since.
Parent
Is there any reason for PPC any more? (Score:2)
Is there any reason to use a PPC these days? At least, for desktop usage?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I don't think IBM makes an workstations that use the PPC chips anymore - but they still use the related POWER architecture in their higher end servers.
So on the desktop, it's dead.
In the device and embedded market, however, it's quite popular. It has an unusual niche "above" ARM and "below" x86, so to speak.
This is because it has higher performance capabilities and better integration with commodity computing hardware than most ARM ch
"revolution" (Score:3, Interesting)
Seriously, x86 these days is just a compression format for a kind of RISC processor. It's probably not a very good compression format, but that probably also doesn't make a big difference.
Re: (Score:2)
Re: (Score:3, Interesting)
As to x86, the major software vendor's complete failure to move platforms (something which that other, different, company managed twice) [...]
What an idiotic comparison. What would the business benefit of moving to another architecture have been ?
(We'll ignore for a second that the "major software vendor's" product has been sold for five or six different architectures (depending on how you count) and internally ported to several others.)