Slashdot Mirror
Is The x86 Obsolete?
levendis writes: "Ars Technica has an excellent article up on the future of the x86 architecture. It touches on new idea from Transmeta, Intel, HP's Dynamo, and a bunch of other technology that keeps the 20+ year old architecture alive and kicking." As always, the Ars take on this (specifically, Hannibal's) is lucid and thoughtful, and grounded in some interesting history.
Engineers can still make allowances in designs to allow for upgrades in the future, even if the nature of those upgrades exceeds the current state of the art. To design a system such that it must be replaced is not what any engineer in their heart of hearts would want to build. Unfortunately, time and money usually forces this circumstance.
"Stop whining!" - Arnold, as Mr. Kimble
Yeah I know, sometimes I seriously think of suicide. Then I remember natalie p.
With a bit of recomiling, I can run the same Linux software on x86, Alpha, Sun, PPC etc. with only a few minor issues. The only incompatibilities are those inherent in C/C++.
... and these "incompatibilities inherent in C/C++" would be...?
:-) The size of an integer changes from architecture to architecture based on the size of the registers, not on incompatibilities in C/C++.
There are none. Incompatibilities arise when the programmers assume a certain integer size (32-bit, usually... I don't know of anyone who writes code which is meant to be reasonably portable who assumes an integer is 64-bits
--
No, the reason x86 hasn't died is because it's as bad as can possibly be without forcing people away from it. Blame Microsoft and idiot peecee buyers for its continued plague of the earth. Modern x86s are an excellent implementation of what is likely the worst architecture ever created. Their "design" to the extent that it exists combines the worst of RISC (hard to write good compilers) with the worst of CISC (lots of useless confusing instructions, nowhere near enough registers) and some extra Intel-specific bad bits (stupid CISC->RISC translation mechanism for example, 16-bit compatibility, nonlinear memory model). What a crock.
and, as per usual, the extra 4bits are yet another hack upon the hopelessly out of date x86 isa.
...reading it made me wonder "wouldn't it be nice if Hannible wrote for Slashdot instead of Jon Katz?"
What a happy thought.
Also realize that all of these instructions are fixed at 32-bits on most chips. That's 32-bits to copy a register, 32-bits for a return, etc. This may simplify the hardware, but at the expense of bloat. So you need a bigger instruction cache.
"This is a feature, not a bug."
It's a tradeoff; yes, it takes more space to cache fixed-length instructions, but it's easier to pipeline them, faster to look ahead, etc. Speed versus space.
The G4's have been pulling a terraflop for a good time now.
No, a gigaflop.
-- LoonXTall
~~~LXT~~~
Life is like a computer program: anything that can't happen, will.
Ok, my car is killing the planet. It sucks up the air. I could drive an electric car, or ride a train, and not do half as much damage. We dump out sewage into water that would otherwise be safe to drink, almost. My office runs windows, a fundamentally insecure OS... Kids shoot heroine... CFC's were banned because they destroy the ozone layer, but really, 3M spoke out against them because their patent on the chemical ran out, they engineered a new chemical, that does all of the damage the CFC's did to the ozone, with the added advantage that it will eventually kill you too and causes alzheimer's disease. None of these have any redeeming qualities, especially by comparison to their cousins... Hell, we sit and watch TV Sitcoms when we could be watching operas or something. I enjoyed La Bohemme way more than I enjoyed Perfect Strangers reruns...
Eh...
I think that Hannibal is dead on with the whole idea of translation technology being built into future chips. I cannot believe that Intel is not trying to duplicate Transmeta's own clever innovations in a manner that does not infringe on patents. And once Intel does it, everyone else is going to have to follow suit.
That's the hardware end. Programs don't just run off a ISA, they also run off an API. What is the software technology that would best run in combination? Virtual machine technology. My gut feeling is that someone will build a PC with the ability to boot virtual Windows sessions where the programs there think they're on an x86 with all the requisite hardware while the rest of the computer is emulating some nicely streamlined ISA and you've got Java code running in some sandboxed virtual machine elsewhere on the system.
At this point you have support for legacy ISAs and legacy APIs in a nice simple format. As computer architectures die, they just end up virtualized and emulated/translated. And the computer is designed from the hardware through the operating system to seamlessly do it. In time everyone assumes they're on a virtual machine and the new operating system evolve to adapt to that environment.
No doubt such a setup will even allow for finetuning for things like emulating old Apple ][ systems as well as original IBM PCs running at 4.77 Mhz to get all those old games running just right. Or old Nintendo/Sega/whatever boxes. All those emulation setups get ported to the virtual machine setup and the appropriate ISA and you've really got emulation there.
Companies will like it because they can ditch old unsupported hardware but keep the software around forever. Especially companies with several brands of hardware/software that they can suddenly run under a single brand of hardware.
This is Microsoft's worst nightmare because all of a sudden switching to a new operating system does not preclude dropping old software. It can be done seamlessly and as gradually as people want. To Apple, it is also a bad nightmare, especially if other people work out Mac virutal machines on other hardware.
To Intel, they're already taking a bruising from the other CPU manufacturers. Intel will take to the translating setup with a vengence, but instead of going in the direction of power consumption (or alongside it) they're going to focus on performance, the niche they've always gone into. And their rivals will go and do the same.
To the PC vendors like Dell and Compaq (but not as I said, Apple) its something to be welcomed. They're already in the trenches competing against other machines that run all of the same software anyway. Anything that allows them to expand their range of software to run, the range of operating systems seamlessly is fine by them.
To operating system vendors (except for Microsoft and to a lesser extent Apple) it will be a major blessing. All of a sudden experimenting with a new operating system becomes easier and switching to it becomes useful. Niche operating systems can thrive being used for specialized applications on an existing machine.
Things like OpenBSD can suddenly start becoming really popular doing things like being the virtual machine that's the only one designated to see the DSL connection to the outside world while the Windows and Sega Genesis virtual machines are there for playing old games and the Linux or FreeBSD virtual machines are used for getting work done.
This is the direction I think the PC will be evolving in to compete with the small and specialized Internet appliances. They are going to take their strength, flexibility and go more so in that direction. The CPUs will become more flexible and the operating systems will capitalize on that and take virtual machines to the next level.
>If you take all of this out, you pretty much
;)
>have a RISC chip. And you'd still be compatible
>with 95% of the code that runs on the Pentium II
>and III. I expect we'll be seeing this kind of
>thing soom from either Intel or AMD.
This is exactly what Motorola did a couple of years ago with the ColdFire which is an m68k chip with all of the naff or complex instructions stipped out. They call it Variable Length RISC because it has a reduced instruction set (which runs a lot quicker) but still retains the compact opcodes of the m68k family. Getting rid of the junk means that a (non-superscalar) ColdFire is a *LOT* faster clock for clock even when compared with the superscalar 68060.
One feature which might be of interest from an x86 legacy code standpoint is that you can run m68k on a ColdFire with the aid of an efficient emulation library that traps illegal opcode exceptions and emulates the instructions. If you pick your instruction carefully the hit from this _should_ be minimal.
Of course if Motorola had done to the ColdFire/m68k what AMD/Intel have done to the x86 the PowerPC would be extinct.... well we can dream
See the URL above for more info.
Once this becomes a more widespread problem, the x86 architecture, in its present form, is doomed. At that point, what the industry will converge on (and whether it will converge at all) is an open question.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
And so does Pig Latin
> Despite this, IA-32 is still the fastest
;-)
> architecture around. The fastes CPU currently
> shipping on SPECint2000 is the 1 GHz Pentium
> III. The RISC architectures are more difficult
> to program, but are also slower!
Wow, that's a real load of nonsense.
The highest performing machine on CPU2000 is the AlphaServer DS20E Model 6/667.
A machine that's running several hundred MHz less than the P3, I might add. It beats it hands down in integer performance, and totally destroys it floating point operations.
Yes, slower indeed!
In practice, programming for the Alpha isn't very hard. It's all a matter of mindset.
The instruction density of IA32 is one of the things keeping it back on its RISC core. The old memory vs. speed tradeoff at it again.
The IBM 360 and 370 series not only had microcode-based hardware, but IBM could and did ship out microcode updates (originally on 8-inch floppy). Among other things, IBM got in trouble with the anti-trust folks because they would send out microcode "updates" that just happened to break 3rd party peripherals - you installed the REQUIRED update and your Amdahl hard drives stopped working, for instance. IBM also would put high-level instruction code support into their microcode. For a long time, IBM's sort software package ran faster than anybody else's because they had microcode instruction assist - kind of a secret machine instruction that the competitors didn't have. It's like the private APIs in Windows.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
Did anybody actually /read/ the article? Hannibal argues that asking whether it is obsolete is not even a meaningful question. x86 was obsolete as soon as there was something more convenient to use. But that's not going to be really relevant anymore because of the advent of third generation chips which will support whatever ISA you want. If you don't like x86, use something else. People have been making fast, successful, "obsolete" x86 chips since x86 was around. Just look at AMD's and Intel's latest processors for evidence of that. The question is whether x86 will be relevant or not.
It's 10 PM. Do you know if you're un-American?
Ah for the days of Zilog's LDIR instruction..
Don't forget the alternate register set! EXX and EX AF, AF' rocked for interrupt processing!
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Oops, my bad about # of regs. Mis-read. :) Still, in a non-trivial, non-leaf subroutine function call overhead isn't a big concern anyway, and the extra instructions are ammortized over the whole function size. If the function is small enough and called often enough that call overhead is a big deal -- that's what inlining is for. But as far as RISC vs CISC goes, the only difference in overhead is code size.
call is not complex, from a uCode standpoint. It sets eip and possibly cs to a new value, and pushes the old values onto the stack. Which is the same as executing a jsr followed by a sta on a PPC machine. call most likely gets translated into the analogs of those very instructions in uOps.
What _does_ make call complex, which is why x86 doesn't implement it directly, is the number of things it wants to use to get it's job done. It uses an alu to calculate the call address, another alu to increment the stack pointer, another alu for address generation, and finally the mem port to do the store to the stack. It has to access the TLB twice (must check that the call address is marked executable). It reads 3 values from the reg file (esp, cs, ss) and writes 2 (esp, cs). From a microarchitecture standpoint, call is very complicated. That was fine, back when only one instruction executed at a time and it had all the cpu's resources to itself. But in a modern o-o-o machine, that's just not reasonable. Which is why intel themselves don't implement call in hardware (well, in the decoders).
Compare this with a floating point operation, which reads 2 values from the reg file, and writes one. That is simple. Which is why modern machines give you FMULT directly, but not CALL.
The enemies of Democracy are
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
I did read the article, and as the next sentence you wrote goes on to explain where my cricicism came from...
Obsolescence is the wrong question here; timothy should be ashamed of himself for titling this Is The x86 Obsolete?
Which I agree with completely. The article was great, the titling left something to be desired. Well.. it's not like this was the first time slashdot mucked up a headline. I just wish they'd change 'em.
I think the article missed a few points on the value of microcode. Microcode allows a CPU to be implemented with a much smaller transistor count than a full random logic design. Microcode ROMs are trivial to layout and verify in comparison to random logic. Bugs in microcode are much easier to fix than bugs in random logic. It takes a great deal of time to design and verify a full random logic design.
Heh, typed faster than my mind thought.
Eh...
Haven't the RISC folks been telling us that since, oh, the X86 chips first came out? Eventually, they'll be right.
-- You see, there would be these conclusions that you could jump to
[sarcasm]A terraflop? Wow, a couple of years ago I remembered hearing about a supercomputer that could barely do 5 terraflops. So i guess there should be couple G4 multi-proc systems on the Top500 list. Oh, wait, no, your just an idiot mac user who is slave to apple and cant get his flop-ratings right [/sarcasm]
I know im going to lose lots of karma for this, but this guy deserves it!
Mark Duell
Address bus width: 36 bit
Data bus width: 64 bit (times 2 busses: cache and motherboard)
Register sizes:
-- LoonXTall
~~~LXT~~~
Life is like a computer program: anything that can't happen, will.
Parse, parse, parse. Ah, this dude actually uses "ko" (and "Ko", of course) as a unit for size, probably meaning kilooctet. Innovative!! ;^)
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
All this stuff aside, there is one very simple, absolutely deterministic way to determine whether something is obsolete: nobody uses it anymore! It doesn't get any simpler than this - the x86 has some redeeming qualities, otherwise nobody would use it.
Except that the Alpha has kicked any x86 chip's butt for quite some time now...
Virtually all scientific aplications I have read about use Alpha chips.
The x86 architecture has always been far worse in floating point operations then RISC chips have been, and RISC chips have been predominate in scientific workstations.
Recently the gap has started to narrow, but tha Alpha is still like 2x faster in fp ops then any x86 chip.
The stack based fp unit of x86 processors suck in every way... Intel has always done a decent job of keeping up in interger, which has been what most comercial apps to this point have used, so has been competive in the end user space..
Blessed are the pessimists, for they have made backups.
All the X-86 specific DOS routines, of which only allow compatability with my old, CGA/EGA dos-based games, could finally be wiped from the bios?
I would bet that emulation would end up playing a large role in these now 'rare' compatability issues..
I heard that one of the reasons why big blue took the x86 was because they were worried about pc's competing with their main frames. IBM at first wanted an 8 bit chip but Bill gates managed to talk them into a 16 bit chip. The obvious choose would have been the 68k but instead IBM went with the 8086 (and later the cheaper 8088.)
Their "design" to the extent that it exists combines the worst of RISC (hard to write good compilers)
;)
RISC is great for compilers, and was in fact designed with compilers in mind. Compilers like lots of registers, and only like to use a certain set of instructions (ld and st, no xlat), and RISC ISA's give them what they want. RISC is intended to make compilers-generated code run fast.
Contrast with Merced, where the compiler is intended to make the chip run fast.
with the worst of CISC (lots of useless confusing instructions, nowhere near enough registers)
The worst of CISC isn't instruction number -- PPC has just about as many -- but that the insts are variable-length and variable-work. A thousand Amens to the register problem, but that doesn't stem from x86 being CISC.
and some extra Intel-specific bad bits (stupid CISC->RISC translation mechanism for example, 16-bit compatibility, nonlinear memory model)
CISC->RISC translation is what lets x86 processors keep up with the RISC machines. It was, frankly, a stroke of genius. Put all the CISC badness in one place - the decoder - and let the rest of the machine be simple. Trying to make a high-bandwidth, out-of-order core that directly implemented x86 would be nigh impossible.
Non-linear memory model is true of any system that uses paging, and is a very VERY good thing. It means that you can allocate a buffer that is 10MB in size, but you _don't_ have to have 10MB of contiguous physical RAM to put it in. You don't even have to _have_ 10MB of RAM to get your buffer. And it's all handled by the OS, invisible to the app programmer. Hooray!
The enemies of Democracy are
Depends how you count it. :)
A first post by me was 5 at one point, then got marked back down to 0. It was regarding the May 2nd DMCA protest that Slashdot refused to cover. Unfortunately I was not able to find it in the archives, as I know I posted it in a completely off-topic article.
BilldaCat
Personally I disagree with and take offense to your statement to your comment.
Some people never learn...no matter how many times something happens to them.
x86/AT archicture is certainly a horrible platform to program for on a metal bashing level. I've been looking at OS development, and from what i've seen already, the whole architecture is horrible and fidly to program for.
The x86 instruction set isn't even that nice; we have extension upon extension that creates a horrible mess of standards and layers, each of which you need to accomodate; a seriously limited hardware interupt lines to attach all important hardware too etc. etc.
Personally, i'd like to see the x86 and the AT die, and quickly, please.
Syllable : It's an Operating System
That compatibility crap is what got us into this mess in the 1st place.
./configure, make, make install.
It takes one day on an Alpha to recompile the GIMP for Alpha if you use gcc. Heck probably not even that long You can't do that without some bullshit World Dominator's Edition of Visual Studio. So the whole compatibility issue becomes a complete non-issue.
And don't give me that crap about it being hard to compile. Three commands:
The message on the other side of this sig is false.
The pentium pro has been a 36 bit architecture for years. Why can't they use the same archetecture for compatibility on the next generation chips?
Intel is backing itself up into a corner with the new 64 bit chips coming up. AMD's new chip is planned to be 64/32 bit compatible.
So in a few months from now, People can either use AMD, or stray to another, faster architecture with software already developed for it i.e. alpha, etc.
It all has to do with software availability, user friendliness, money, and speed.
http://siokaos.org/
...this is WAY more answer than we needed. Here's what Slashdot wants to hear (and all it can understand): "x86 will die a horrible flaming death in 9 months. Also, it's girlfriend will leave it."
--
Compaq dropping MAILWorks?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
For that you can thank Microsoft's amazing track record at porting to different platforms.
Even when NT did run on stuff other than x86, Microsoft was not alone in not porting many apps... No one else did either, except for the VERY few that wanted to/needed to eke out the extra performance.
And it's not just a Microsoft problem. Linux run on close to everything under the sun, but can you run Oracle 8 on anything but intel? How about DB2? WINE? WordPerfect? How about even Netscape 4.x? They all are available for x86 and eschew platforms such as SPARC and Alpha.
x86 isn't going anywhere, no matter how much intel and everyone else wants it to. It's popular because it's popular because it's popular....
Why is this still at 0? Moderate it up!
---
Zardoz has spoken!
Oper on the Nightstar
The article has nothing to do with the question "Is x86 good?" Arguments about this question are therefore off-topic. As has been pointed out, most of those posting do not seem to have read the article. The crux of the article seems to be the shift toward abstraction that makes the architecture question not so important. When I write code for the x86 chips (and others), I'm actually writing code for any number of (present and) future architectures that may have little to do with x86. "Write once, run anywhere," in Java terms.
Donate background CPU time to fight cancer.
Transmeta's crusoe is the first of a generation of processors that can execute X86 efficiently without having a hardware implementation of it.
No, both modern Intel and AMD processor decode x86 instructions into microcode in order to process them.
Jonathan David Pearce
Jonathan Pearce jonathan@pearce.name
3EAAFB2A http://www.jonathan.pearce.name/
...and now, Win2K runs on x86, and x86, and x86, and x86 :)
I had to do a double take. I thought it was "BuildaCat"
That may be a great idea for a website...
they don't? i run 68K apps such as Illustrator on my iMac no problem dude, theres a little calculator app i like that was written when the MacPlus was cutting edge. it works fine still!
As for Mac users howling, you bet they did. When I told a guy I worked with that his 3 year old mac was too old to play a game he got for his young daughter he was pissed.
so u mean 3 year old PCs can play new games? often not the case
It can be done, and the ARM ISA is absolutely wonderful, the best ISA ever in my opinion. The Intel StrongARM might be reaching 600MHz this year, and still only be gobblin' up 1/2 a Watt of power, but what could a 60W 1GHz StrongARM do?
NT4 runs on high end PowerPC hardware, not Power Macs.
--
Maybe next time hesitate with the automobile metaphor:
Yeah. This is akin to a beaten-up, smoke-belching old piece of crap whizzing down the freeway at a stunning 40MPH.
But, you know, if you add fuzzy dice, UFO lights and a big stereo, the owner will think that you won't notice that the thing is a worn-out piece of crap.
I would like to point out that all of the current automotive engineering strategies were designed within the first 20 (or so) years of production (with the exception of the wankel, emission controls, computers and abs all the rest is but refinement of obviously antique technology)
All of the super-turbo charging, multi cam 12 cylinder fuel injected goodness appeared at the dawn of the 'architecture' of the automobile. This does not impeed modern vehicles from ass kicking good performance in the slightest. The refinement of that platform has aged gracefully, and I argue the same for x86.
Mechanics are familiar with the 'internal combustion' architecture, the way deep coders and ee's are familiar with 'x86' architecture, and this serves to grease the skids towards wide spread acceptance and ease of use for both technologies. I guess this is the 'inertia' you speak of in action, but can you really argue that it is a bad thing? I don't think that innovation is always the shortest path between two points when you throw infrastructure into the equation.
I guess you could maybe consider the deisel to be analogous to the mips stuff? how bout electric/hybrid electric cars as the PPC? either way, metaphor or not, they were all designed at the turn of the century/in the 80's
-=(\/) | (\| | - (\/) 3 (\/) 3
Wait, Help me out here, but can't much of the slag that is the ancient throw-back compatibility be dropped? I mean, in the days where I can emulate anything from a c64 to a PSX on my desktop, why do I need hardware AT/8086 compatibility? just my $.02
semantics are everything!
Ok, we need to go over this again, someone marked this post as offtopic. Signal_11 made a post saying pretty much, that since people use the x86 processor series, that it can't be obsolete, that people don't do stupid things like that. What I was saying, is that we do stupid things like that all of the time, and use a lot of things that are obsolete, so the processor could have been, and was obsolete from its conception, and still fit the requirements of something that he claims is not obsolete.
Eh...
Actually the occurance I was talking about happened several years ago so his mac was a '93ish model that he was trying to get to work in '96ish. You can say the equivalent of upgrade blah blah blah, but frankly he was forty-some year old menswear clerk so you might as well have told him to fly to mars.
So far I've gotten all my Karma from telling people they are wrong... :)
Hmm. I am writing this with Netscape 4, on a Sun Ultra. Would be a bit hard if, like you said, the software wasn't available for SPARC...
The x86 is hardly obsolete, except maybe in our own little world. For parts of the world that don't have the income to lease a new SUV every two years, the cheap x86 clones are cutting-edge technology and will continue to be around for quite a long time.
It's cool to have newer, faster, better hardware but does it actually let you get more work done or have more fun? For a few individuals, yes, but the vast majority of us have had computers faster than we can type for a long, long time.
Don't make something obsolete when something better comes along - make it obsolete when it ceases to be useful. I still use a 486 as a simple mail and web server just fine, thank you.
The AX accumulator register is a hereditary link back to the 4004 calculator chip that the x86 line springs from. The fact that it works as well as it does for general computing reflects well on Intel (and AMD and anybody else who markets a usable x86-ish chip), but that ingenuity would certainly make better-designed chips that much more impressive instead. I do think that the x86 family will be around for a long time, and I do have some affection for it. It is what I can afford, and its weaknesses drive compensating technological advances in exactly the same way that bloated code from Microsoft has driven faster CPUs, more RAM and more storage.
--
JADBP
You overgeneralise. Differing integer sizes has been a common problem for C programmers over the years, but it doesn't take much badgering to get them to use the sizeof operator (getting them to use CHAR_BIT takes a bit more badgering for some reason). However, especially when dealing with I/O, binary representations (e.g. endianness, how signed integers are stored, how floating-point numbers are stored), programmers still make a lot of assumptions. This is harder to overcome, mainly because there are no hard and fast rules, and so the programmer has to actually think.
I could go on. Just a few other silly assumptions C coders make: assuming an ASCII character set, passing NULL or a pointer to non-void unadorned to a function out of scope or without prototype (or even worse, passing 0), doing other stupid things wrt NULL (calloc()ing an array of pointers, for example), getting overly familiar with their implementation of va_list (which causes problems for platforms which, for example, push arguments in the opposite order), etc.
Of course, as you've said, none of these are shortcomings of the C language.
While I would like to see the x86 hardware go away, it gonna be around for a long time. I think the real issue is how you get your legacy code to run on different OSs. Your win9x/NT apps don't run on linux/x86 yet they have the same hardware. To solve this kind of problem, all the OS will need to do what the microcode is doing. That is have a low level OS that runs between the user OS and the hardware. Which pretty much sounds like a MACH microkernel. If MACH was more widespread then legacy might not be as big an issue, but code will always need to be updated to the latest User OS.
Just some random thoughts.
Brought to you by Team SPAM! where we believe: "Information in the noise!"
The x86 architecture's design is hindered by backward compatibility requirements, making it significantly less efficient than chips designed from scratch. A powerful Pentium-class CPU burns significantly more power than, say, an equivalent Alpha or PowerPC, and dissipates more heat. The maximum speed, and maximum performance, of such a CPU are inferior to newer designs. And in order to perform reasonably under modern conditions and retain compatibility, such a chip is necessarily much more complex.
The only reason that the x86 has stayed around is market inertia and economies of scale. Because of the large scale of manufacturing, x86 machines are a lot cheaper than newer architectures, and most binaries are for the x86. Rather sad, really, but that's the way it is.
Heh, what up spiralx? Go post something on Smokedot instead of reading this crap :-)
:-)
Anyway, I smoke weed like a fiend - every day, if I can help it. And I get tons of stuff done. I work full time, write open source software, do CGI art, and other stuff. I can't usually get anything done if I'm not stoned though
Alright, this is drifting way off topic.
--
I was referring to the "segment" concept, the fact that physical memory is nonlinear (or however you prefer to describe it. The point is that pointers require two registers.) Thankfully protected mode helps somewhat and makes it possible for an OS to offer virtual memory and a linear address space, but the fact that 16-bit real-mode segmented address spaces still have to be dealt with at all, ever, is obnoxious and stupid.
I use the term to mean factor of 2. Adjust accordingly if your definition is different.
besides, that isn't the point at all. software licensing techniques do not impinge on the obsolesence of the instruction set.
-=(\/) | (\| | - (\/) 3 (\/) 3
Excuse me, lad. If you don't believe I'm smart, just read my bio. I don't usually brag about it, but this is an insane comment. I don't use any of the operating systems you mention above at work. I do use Tru64 and Solaris.
Windows 2000 is the flavour of the day, it seems to me. Everyone is touting it's stability and speed - reminiscent of the Windows 95 hype. (Instability on PC's is a thing of the past and crashes will happen very rarely due to the new 32-bit nature of Windows 95 and the excellent system design implemented by Microsoft. Heh, sure, guys:) Windows NT was touted as a UNIX killer. 6 years down the line, UNIX is still around and NT is somewhat of a joke, at least in my field of work.BeOS is way overhyped. I managed to crash it by typing in a URL in the Opera browser, and opening more than 10 windows (mp3's), which theoretically shouldn't create a problem due to the amazing RTOS kernel, slows the thing down to unusable levels (killall mp3 time, perhaps even rebooting if your terminal doesn't respond). No doubt, it's a sound idea and has useful applications - Video editing blah blah, but a lot of it's just hype.
MacOS. OS X sounds promising, but I'm not sure how much it will deliver. I'm guessing not as much as it's promising. MacOS 9 and below are sitting on a 15yr old feature set, still use cooperative multitasking, have goofy memory management and aren't very user friendly, after all. (where's"A few atoms won't even light a match" - Dr Jones, 1933
...or he's French. There's no other word for Byte in French.
1,44 Mo => 1.44 MB
and so on.
Hands in my pocket
I don't want to pretend to be an expert, but isn't the biggest limitation with the intel processor the Bus architecture that can only let one chanel of communication between two devices happen at one time?
I know that with SGI hardware they have a type is switched bus that allows multiple devices to talk at the same time which allows for much higher sustained bandwidth.
Does anyone know if x86 chips can run on a non-bus architecture or is it part of the Chips instruction set to function on bus architecture?
Yah, no, that wasn't the way I meant it. I was thinking of an old worn-out 1977 Celica chugging down the road as a metaphor for an aging platform, with a particular view to the ALU and other parts of the processor and underlying microengine infrastructure that are forced to maintain compatibility with not just legacy apps, but *way* legacy apps.
I would like to point out that all of the current automotive engineering strategies were designed within the first 20 (or so) years of production (with the exception of the wankel, emission controls, computers and abs all the rest is but refinement of obviously antique technology)Oh yeah, absolutely. After Daimler and Benz were able to figure out the first two-wheel steering system (and cars ceased to be three-wheeled), the progress was staggering, but many of these refinements were limited for the first few decades of the automobile by limited machining ability (cost), metals quality, etc.
When I look at an old Bugatti and see an overhead cam, supercharged, mechanical fuel injection engine that was built in the 1920s, I can't help but be impressed. On the other hand, these really weren't workable for more affordable cars until fairly recently. Much the same way hard disk drives didn't hit personal computers until the mid-1980s, though they were a 1950s invention.
As a symbol of the antiquity of the rest of the vehicle, despite the OHC/FI/supercharged engine, the technology hadn't progressed to the point where a modern, workable, x-shaped universal joint was possible. The universal joint underneath this Bugatti is what is referred to as a "rag joint" - a sheet of rubber-impregnated cotton is bolted to two plates. One spins on the transmission's output shaft, the other one carries the force to the wheels. As the differential/back axle rides up and down in the suspension's range of travel, the rag joint deflects just like a modern roller-bearing U-joint. But the size, weight, inefficiency and failure-prone nature of the rag joint is just astounding in comparison.
To use your interpretation of my automotive analogy: much the same way as putting a new Mopar Performance 528CID crate Hemi into a 1920s Bugatti would be a bad idea (without getting into destroying the originality of the car, you'd simply tear every last piece of the drivetrain apart the second you took your foot off the clutch and the leather-faced friction surfaces hit the flywheel), my thesis continues that it's probably an equally counter-productive thing to try to constantly add things to an aging architecture. Protected mode (286/fixed by 386), coprocessors, dual instruction pipelines (Pentium 60 and up), MMX (Pentium 166MMX and up with desktops), etc.
If you want a Hemi-powered Bugatti, by the time you've got enough experience and money to have your hands on either a Hemi or a Bugatti, you'll probably know that it would be a better idea to build a new car from scratch that simply *looks* like a Bugatti, without actually trying to put a Hemi into a Bugatti.
I like the Transmeta, for example, because it "looks" to an operating system or application like it's an x86 processor. But, of course, it's not. And, while I don't know how many hardware sacrifices were made to make it look as much like an x86 as possible, given the software translation scheme, I'm sure they've got a lot less sacrifices to the history of the x86 line than a PIII or Athlon.
Getting away from cumbersome, seldom-used and antiquated overhead will simply improve performance and provide a good platform from which to develop further.
Fire and Meat. Yummy.
Oh wait, zilog still sells a lot of those little buggers for embeded systems etc. With so much code written for the z80, and the z80 in so many system I guess it will be a while before it dies.
If the z80 is still kicking around after all these years, imagine how long it will take to get ride of the 68k or X86? Face it the X86 ISA in one form or another is here to stay! How many mission critical apps are written for it? I guess if you read the article that was the author's point!
> Heh, typed faster than my mind thought.
I could type faster than your mind thinks with a straw up my nose.
jon here has obviously not read the article. in the context of the article, his comment should be rated (-1, off topic). /. coming to? this is like a lot of people discussing THE WRONG THING.
to the moderators: read before you rate.
what is
i guess part of the problem is the title of the post:
The article does *NOT* state that x86 is obsolete. go read it, it's good.
And it is proving to be popular. However, it's going to be quite a while before someone writes a Java/C interpreter/compiler/emulator/translator that can provide a good enough environment in which to produce something like Quake VIII.
No, they do get it. They know that the market is ready right now for the technology that they're providing. Java, on the other hand, is relegated to the non-gaming segment until more advances can be made to the technology. But you're right - this is the approach of the future. It will become more and more mainstream.I'm a leaf on the wind. Watch how I soar.
It's not necessarily true that RISC code is good for compilers. ARM assembler is pleasant to code by hand, but most compilers generate relatively poor code for it. At least, gcc was not blazingly fast on ARM last I checked, and neither was Norcroft C.
-- Ed Avis ed@membled.com
It's not all the instructions that make it suck (IMHO). It's the sad lack of general purpose registers and that ridiculous segmented addressing scheme.
If the characteristics of diverse hardware implementations could be codified in a standard way, then we could create "drivers" for each different architecture, that would enable compilers to optimize their code for that particular product. Granted this is way more complicated than say, a sound card driver, since optimizing code is way more complicated than playing a
Yo dawg, I heard you like the Ackermann function, so OH GOD OH GOD OH GOD
The 8086 is not what I'm criticizing. Yes it sucked but so did everything else at that time. What I'm criticizing is the decision of the engineers to let the marketdroids run Intel and thereby prolong the life of a design that had no business surviving past 1988 or so. In the mid-80s the SPARC and MIPS projects were starting to produce marketable CPUs. These CPUs were well-designed and well-implemented, and fast. Intel's engineers are more than capable of competing with such offerings, but they chose instead to allow non-technical idiots to dictate technical policy. Specifically, the 486, Pentium, ... are mistakes and deserve to be treated as such. These CPUs should never have existed because Intel should have abandoned an architecture that by the time of the 386 was already aging very badly. I will gladly excuse technical mistakes made in the absence of information we have today. I will not excuse bad policy decisions which should have been made by engineers, made instead by braindead marketdroids.
In legal-speak, I'm saying that Intel knew, or should have known, that their current product offerings were technically inferior to those of their competitors, and should have adjusted their product line accordingly.
The i860 and i960, along with the ability to manufacture x86 CPUs that offer any performance at all, prove that Intel has a great many competent, if not brilliant, engineers. Their mistake was in giving up control of the product line. When Intel's marketdroids announced the 486, every Intel engineer should have either demanded a change, or cut and run. There is no excuse for the continuing existence of the x86.
I got modded as interesting, and you as insightful? I was thinking it should be the other way around. Anyway, glad at least someone got the point;)
Jesus was all right but his disciples were thick and ordinary. -John Lennon
As long as you're not hand-coding assembler, the compiler is what's picking the instructions that will be used. Why don't the compiler vendors and the processor companies work more closely so we can eliminate some of these 'dead' instructions in future systems?
Not that it matters - as the Ars article points out, the new systems really translate and emulate the ISA, and turn those instructions into things their internals can process. Now, when folks complain about Java bytecodes, I can rebut with the fact that their "native" code isn't really running on the raw hardware - it's emulated, too.
I love vegetarians - some of my favorite foods are vegetarians.
Yeah. This is akin to a beaten-up, smoke-belching old piece of crap whizzing down the freeway at a stunning 40MPH.
But, you know, if you add fuzzy dice, UFO lights and a big stereo, the owner will think that you won't notice that the thing is a worn-out piece of crap.
The introduction of protected mode, while a vast improvement over the previous situation, basically underscores the tacked-on cludged-up nature of everything since. The 286 was the first protected mode Intel processor. And it could switch into protected mode, but required a reset for switching back to real mode. This is like having a really nice new Alpine CD player where you have to coax the CD back out with a bread knife.
The x86 architecture hearkens back to 1971, when Intel unleished the 4004, which was a 4 bit hand calculator processor. The 4004 begat the 8008, which begat the 8080, and from whence sprang the 8088, 8086, and then finally the 80186 and up. This processor family shares many things in common, including a similar basic architecture that makes the chip better suited for ASCII (text) data than it is for binary data.
That makes the x86 family *almost* 30 years old. Now, if we compare the advances in computers in the past thirty years to the time it took to make a similar paradigm shift in architecture, you'd see that we've got the World Trade Center and Sears Tower now, but just 30 years ago we were living in straw huts.
In maintaining the same basic architectural features of the 4004 all this time, it's basically akin to trying to build the Empire State Building with sticks and mud. Welcome to the computer industry, 2000.
Sure, a lot of great stuff has been done in and around this processor. But we're really stuck with it only because in 1981 when IBM brought out the PC, they wanted to be anything but radical. From an engineering standpoint, especially with a vision to the future, we would now have machines literally twice as fast per CPU cycle if they'd chosen the then-new Motorola 68000. Every PC/XT would have had the power of cooperative multitasking and a processor that was designed as an industrial controller and so relished the real-time multimedia apps we love today. The development process would have taken us through the 68010, '020-'040, and finally up into the PowerPC variants. Not to embrace Macintosh too much - I love their Motorola CPUs, but I don't use one too often - Windows 95 = Macintosh 84. That's a processor issue too, not just an eccentric genius designing the software.
Who'd have thought, 20 years later, that the lowly and conservative platform they released would be the foundation for today's computers?
Is it out of innovation, or inertia?
I suspect the latter.
Fire and Meat. Yummy.
I tend to doubt it. Remember, the "high end" Intel chips are generally just consumer chips with different cache architectures. There aren't any substantive differences in the processor itself; it's cheaper that way.
--
There is no sin except stupidity -- Oscar Wilde
Seems that most people are missing the point here.
We only need x86 translation because so much software exists in binary-only form. If all software were Open Source, then the issue wuld be moot. With a bit of recomiling, I can run the same Linux software on x86, Alpha, Sun, PPC etc. with only a few minor issues. The only incompatibilities are those inherent in C/C++.
Sould the question then be "Is C obsolete?".
However, you do _not_ have to save all 32 registers, unless you use all 32. You only have to save the ones you are going to use.
I never said that. I said 15 or more. On the PPC, 15 is about the max. In general, though, there's about 15-20 instructions of overhead in a non-trivia, non-leaf subroutine (in C), but it can be twice that.
You need to stop and think about what "complex" means. A CALL instruction is not complex. Heck, it was standard on 8-bit processors with less than 10,000 transistors. Complex instructions are some of the crazy things done in hardware on the VAX and IBM 360. If a CALL instruction is considered too complex to implement efficiently in hardware, then we shouldn't even both with things like texture mappers or floating point math. The bottom line is that RISC has gone over the top, making things more simplistic than we really want.
Bill Gates was just a tiny little software vendor at the time. His competitor was Digital Research, with a thing called CPM/86. The decision to use the 8086 was made long before Bill Gates even got involved in the process. He was just a software vendor, with no input at all into the design of the machine.
Maybe he had delusions of this type of grandeur, but no footing in reality at the time.
The 68K didn't even exist yet. The Apple Lisa, which was the predecessor to the 68K, was still about 5 years away. Even the 6502, which the Commodore 64 and Apple II used, didn't even exist yet.
The obvious 8 bit choice would have been the Z80 or the 8080 (more likely the Z80). That Z80 was the standard chip for the late 70's CP/M machines. It is possible that Intel had some input on using the 8086 instead of the 8080. The reason for the 8088 was that is used 8 bit bus architecture, which allowed IBM to leverage cheaper motherboard designs. 8086's were simply too expensive to build at the time - an 8086 PC with a green mono monitor and two floppies was somewhere around $6000.
--- "So THAT's what an invisible barrier looks like!" - Time Bandits
I have a concept where the motherboard is a thing of the past.
Get rid of the ISA bus, PCI bus, memory bus, serial ports, parallel ports, and the AGP bus.
Replace everything with a gigabit switched ethernet network. Each computer componment on the box is connected to the switch with two twisted pairs, one a send and the other a receive. They are also connected to the 5v and 12 volt power supplies and a common point ground.
The CPU only has power and a gigabit ethernet connection.
The ethernet card is a pair of ethernet connections with a network address translator in between that acts as a gateway between the internal and external networks.
Memory also only has power and an ethernet connections and sends back information to the device that requests that info. This allows multiple devices to all send and recieve data simultaneously from memory. It would even be possible to have dual ethernet ports on a memory card to double the bandwidth of the memory, or to put multiple memory devices in a computer and then sharing them between and amoung devices.
Harddrives also would have only power and ethernet connections and would look and work simimilar to a memory device.
This allows any number of computer components to be clustered together by connecting the switches of "boxes" together with a strait through twisted pair. The number of compoments is limitted only by the size of the box and the number of connections the switch allows.
Your external components are also connected directly to the main bus with two twisted pairs, giving your monitor, speakers, printer, keyboard, mouse and joystick the same level of connection as the rest of your internal components.
The idea and information contained within are hereby released into the public domain. Any use of this design in real world applications is free and may not be patented in any form.
What does everyone thing of my design? Is it feasible?
-- Never make a general statement.
I see you threw Wine in there. In theory Wine would run fine on any other platform, but there isn't much purpose for it. Wine allows you to run windows binaries, which are created for x86. Even if you managed to port wine to Sparc for example, what sparc win32 programs would you run?
I wouldn't be surprised if winelib was ported though.
Some of us have been trying for a HRFP (Highly Rated First Post) for quite a while. My best was only a three. But I have seen one or two 5s. It's just one way to take /. back from the trolls.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
Wow, what an outrageous load of FUD this is.
As for Mac users howling, you bet they did. When I told a guy I worked with that his 3 year old mac was too old to play a game he got for his young daughter he was pissed. He should be, by ditching compatibility like that it destroys any value his 3 year old computer had whatsoever.
Well, you shouldn't lie to people like that. I run UT, Falcon 4.0, and a number of other interesting things on my 3 year old Mac. Maybe your Mac-user friends will wise up and stop asking you for advice on things you know nothing about.
--
NetInfo connection failed for server 127.0.0.1/local
Winchips have found a home in the I-Opener, as some others have mentioned, but also in the hearts of those of us who'd otherwise buy Cyrix (another decent brand if you're willing to trade performance for money...)
It's a Winchip that's currently powering fojar, hatelife, and yellow5.
ARM is an embedded processor... while I'm not that up on embedded processor uArch, given the vastly different design considerations for the embedded world, i'd wager that affected the ISA to the detriment of compiler happiness. *shrug* but I'm just speculating.
So, I ammend my statement to only include those not explicitly designed for embedded systems - PPC, Alpha, Ultra Sparc, etc.
The enemies of Democracy are
Chemical dependance...good...you've identified your problem.
Not quite... while chemical dependance is a good way to describe my relationship with nicotine, it's not with THC. I could never get anything done before I started smoking pot either. I was always very lazy... the only time this isn't true is when I smoke some nice kind bud.
--
Well, the book says 1975...
Everyone should have H&P (both of them!). They are incredibly good, in my (and many others) opinion. CA:AQA could stand a third edition, though - the 2nd ed is starting to show its age.
This is from the m68k faq http://archive.comlab.ox.ac.uk/cards/m68kfaq.html
"1) Motorola 16/32 Bit Product Line:
=====================================
Motorola introduced its first microprocessor in 1974: the 8 bit MC6800 with
an extensive line of support peripherals soon available. The MC68000 was
introduced in 1979 and was soon followed by a host of 16 bit peripheral
chips. The 6800 and 68000 families soon became very popular due to their
straightforward architecture and simple and easy to use bus connections.
The first member of the 68K family - the MC68000, is not software
compatible with the 8 bit 6800 series which includes the 68HC11 series.
The 68K family itself is upwards software compatible."
So it seems that big blue had more options in 1980 or so than just the z80 and 8088. The story about bill gates talking big blue into a 16-but chip and ibm choosing the 8086 (and then later the 8088 there were a few very expensive xt's based on the 8086 although they are rare) is from Bob Cringley's book "Accidental Empires." This is a little bit before my time so everything I know about this came from reading books like that.
The comments on how to have different platforms be binary compatible are interesting in their own right. What I find interesting is how the same idea in a different form is implicit in what Torvalds writes. For instance read his essay on the kernel from Open Sources carefully. Here is a more technical explanation. In both cases you abstract out from the architecture, OS, library, whatever the interface you want to program to, and then (with appropriate macros etc) set up that interface. Then when you go to port it, you merely need to figure out how to set up all of your macros and the bulk of the code remains untouched.
Look at that sideways. That is *exactly* what IBM did to make code binary portable. That is the principle that the AS400 uses. If you peek in well-known and widely ported projects (eg Perl) you will often find that they take the same approach. (For good reason!)
The key to wisdom lies in seeing how good ideas about foo look like good ideas about bar and then trying to apply that. There is a good lesson here about portability...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
I've had some minimal experience with some Cadence tools running on Solaris workstations. I wonder if they could possibly run as well under Windows.
Anybody?
--
I also am somewhat dubious of your claims concerning the 3 year old mac. In '97 you're talking 604s at 180+ Mhz (4400s,7300s, 8600s, and 9600s) that should run all of todays software without any problem, at least as well as a P200 would on the other side of the fence. The only powermacs without an upgrade path to at least a G3 are the original PCI based macs (7200s). Those were doomed machines from the start though (the whole Carl Sagan thing ;)).
The only machines that have been totaly ditched, support wise, are the 68k machines. 68030 and below based macs (9+ years old) were dropped with OS8 and 68040 based machines (7+ years old) were dropped with OS8.5. That's allright though, just throw a BSD on the thing and go to town.
The Performas are a different story (although it's been nearly 5 years since they quit making those junkers) but then again so are the PS/2s.
Insanity is the last line of defence for the master diplomat. But you have to lay the groundwork early.
Is it just me, or has everyone forgotten that IBM's lovely little solution, the AS/400 has been doing this sort of things for more years than I care to remember. IIRC, it's been through at least 3 different generations of processors, and while all being wildly different, the translation has taken care of it all. No re-compiling. Once, when we went out to a site, someone gave us an AS/400 from way back when. It was slower than dirt, but it ran everything the shiny new one in the datacenter runs, despite having a different type of processor and probably everything else, too.
Hell, the thing still runs 30 year old System/36 programs. I should know, given that one of the people I work for is still using such a beast for accounting. Ah well, one day Intel or someone will figure out how to do the same sort of thing.
I just can't wait for Linux on the AS/400... God love IBM.
Care about freedom?
Become a card carrying member of the GOA.
Never for performance reasons. Computers than run x86 instructions are business machines designed to be cheap and ubiquitous. Faster platforms and more elegant ISAs exist, but they still don't have the acceptance that x86 machines do. I don't believe they will until x86 machines are no longer a market force.
When power requirements and die size become paramount. Everything Intel and AMD engineers currently do to make their processors run faster requires additional hardware. All this next-generation translation business requires additional hardware. The Crusoe chip does not throw additional hardware at the problem, and suffers a performance hit because of it. An ISA designed to be implemented on a low power, teeny-tiny die should kick these chips butts. Such a chip is a requirement for powerful embedded systems, like those that might fit in your pen or glasses or cell phone.
When 64 bit memory addresses are required by the majority of users. In my opinion, this is one of the most fundamental limitations of any 32 bit architecture. With time (a lot of time) 64 bit memory addressing will become a must, and that will mandate widespread adoptance of 64 bit machines. I don't expect early adopters of 64 bit platforms to be in short supply, however; they're already out there.
Jonathan David Pearce
Jonathan Pearce jonathan@pearce.name
3EAAFB2A http://www.jonathan.pearce.name/
ok, I don't know where that moderator gets off, but my post was NOT redundant. I related a personal view. Redundant?!
Whoever you are I hope you run out of points soon.
In my assembly language course, the instructor felt compelled to teach the java virtual machine(jvm) and x86 architectures. This was done as an experiment, and one of the reasons cited was that the x86 architecture had just become so victorian that it was time for a change. Essentially it became a course where we compared and contrasted the two architectures(btw we had to write twice as many programs too). Along the way we were informed of some the brain damaged designed decisions which manifest themselves in the x86; Decisions that were made in the late 70's, realized as mistakes in the early 80's, and perpetuated to the very day. This includes things like byte ordering and memory segmentation in the x86. This particular instructor felt that virtual machies were going to be a big part of things in the future, and hence the choice of teaching the jvm along side the x86.
It has been for at least 10 years now.
64-bit RISC architecture has always been the superior platform.
Of course the x86 is obsolete, but Intel hasn't yet figured out it could make buckets of money following Microsoft's lead, by making PC users upgrade -- first to x95, then x95 OSR2, then x98, and now x98 SE.
:)
Folks,
I find it very amusing that people think the x86 CPU architecture is obselete.
That may have been true for the 8086 with its 1 MB memory addressing limit and the 80286 with its 16 MB memory addressing limit, but once the 386DX with its 32-bit flat memory addressing scheme became available, in theory the x86 can address as much as 4 GB of system RAM! It's mostly memory physical limits on the motherboard and motherboard memory controller chip limits that has limited computers from addressing all 4 GB until now.
Besides, the x86 architecture has undergone an unbelievable increase in performance. Remember when the first 386DX CPU's were rated at a meager 12 MHz 15 years ago? We now have Pentium IIIEB and Athlon CPU's running at around 83 times the clock speed of the original 386DX and vastly better memory management.
Besides, very few programs for stand-alone workstations demand more than 256 MB of RAM nowadays. And most server applications run extremely well with 1 GB of RAM, especially on the Linux server machines.
The big bottlenecks are no longer the CPU; it's mostly hard disk access times and access times through the network adapter card that holds your system back. Now you know why RAID 5 hard drive arrays and Gigabit Ethernet NIC's are used on high-end servers.
However, I do see that non-x86 architectures may become more prominent in the next three to four years. Projects such as LinuxPPC will allow Linux applications to run on systems that use the PowerPC CPU, a CPU with superb memory addressing capability and an equally superb FPU unit. If Linux becomes popular enough, maybe we might even see a revival of the PReP platform in an updated version running LinuxPPC, machines sold to people who need serious FPU processing power such as engineers and computer animation artists.
Raymond in Mountain View, CA
Ok, these two questions poped into my head when I was reading this:
If all your programs are GPLed does having an open standard ISA really matter? Each time there is a new design you could just recompile (assuming the compiler and things like assembly part of the OS were re-written.)
Is there anyway to write code for the athlon or any newer chip that skips the front end decoder and goes straight to the back end? Would there aver be a reason when this would be a good idea? (ultra optimized athlon code.)
Just wondering.
X86 is a thing of the past and should be laid to rest. Not just because its old technology, but because there are much better architectures available now.
Actually, the octohexal-CPU mother board lives up to that long sought interconnectivity between appliances...no need for complicated communication software- House cold? Turn on teh computer! Need to cook something? Load up a game of quake XVII, slap the griddle over the heatsinks, and voila! Want that hot shower? Not to mention the possible applications as boiler, water heater- hell, these will be central to our lifestyles one day! See! Its far from obsolete!
Actually, I'm "funny". I'm surprised no one responded and said "I don't get it; Linux is a *nix variant!", to which I'd have to respond "Ah, but the original post said '*nix' and we all know that linux is spelled "Linux, not 'Linix."
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
When Intel's marketdroids announced the 486, every Intel engineer should have either demanded a change, or cut and run. There is no excuse for the continuing existence of the x86.
Forgive me, I'm not up on the details of Intel history. What alternative did they (that is, Intel et al) have? They seem to have viewed themselves as bound by the same strictures as Microsoft: backward compatibility. You say they should have abandoned the x86 architecture. Would this not have forced them to walk away from one of the most, if not the most, popular/lucrative chips on the planet? I suppose they could have emulated x86 code, but then what do they tell the hundreds of thousands of businesses worldwide that already have x86 computers? "Buy our new chip: it'll run all your old applications, only a lot slower!"
Would it have been slower? Did somebody, even Intel, try this? What happened?
I just wanna know why you think scrapping support of the x86 architecture would have been a valid business decision?
My
I guess you never learned the first rule of programming.
Never critize those who came before you. They didn't have the benefit of your knowledge.
All of these nifties, coupled with the low-power consumption and lack of integral FPU, means that ARM is very attractive for non-desktop applications. Desktop PCs, as it has been shown over and over, can succeed despite having some of the most poorly engineered technology imaginable.
I thought the fastest cd-roms could only go about 50x. Wow, technology is incredible!
----(o)----
The ISA were thought out for easing the task of compilers, not human!
That's why you can find hand-coding in assembly for RISC more difficult than for a CISC.
Read Hennsy & Patterson: Computer Architecture, a quantitative approach to understand why RISC CPU's are making those trade-off.
Define "nobody" and "uses".
By strict definitions, horse 'n' buggies, vacuum tubes, Windows 2.0, steam engines, and roman numerals aren't obsolete.
--
Compaq dropping MAILWorks?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Do you come from another planet or smoke crack on a regular basis? Macs have *always* had better backwards compatability than PCs, *especially* on the software side. Hell, when they went PPC from 68k there were a good two or three years where you could run new stuff on a 68040.
OSX might put a dent in that otherwise stellar track record, though.
just my blog and pix
What makes the x86 a major proctalgia is the nonorthogonality it inherits from the 4004 et al.; nearly every register is "magic" in some way, i.e. there's some instruction that requires an operand to be in that register, so that you spend a lot of time maneuvering values into and out of the magic registers. (Admittedly, the SH is at least as troublesome, because there, it's one register that's magic, i.e. R0...but OTOH, that arises from its use of fixed length sixteen bit instructions, which undercuts the "code bloat" argument somewhat, as does the "THUMB" mode on ARM and "MIPS-16" mode on MIPS.) There aren't very many registers, so that more variables get to live in memory than on typical RISC processors.
The RISC machines aren't without their hassles, most notably the Procrustean instruction length which constrains immediates and displacements, but that's far less hassle than the x86.
Hardly. Whilst I don't know of anyone that likes the x86, saying that it's obsolete is extremely premature - look at the increases in processing power that have gone on over the last few years and are still continuing with things like Athlon's forthcoming Sledgehammer.
The fact is that despite its poor design chip makers have done some amazing things to push it to greater speeds - the Athlon CPU looks and works nothing like the 8086, they just happen to run the same instruction set. And in this year we'll be seeing the GHz barrier broken - hardly the sign of an "obsolete" chip is it?
As long as the chips are still getting faster and people are still buying them I think calling the x86 platform obsolete is incorrect. A pain in the ass? Sure, we'd all like a brand new chip design, even Intel, but it works, and it's still growing.
---
Jon E. Erikson
Jon Erikson, IT guru
A reasonably configured used O2 in perfect condition can be had for under US$1500, about the same price as a midrange peecee. An R10k High Impact Indigo2 can be had for about $1300-$1700 as well.
:)
That's not what's holding me back. It's that $15K for Alias|Wavefront Power Animator, or $5K for Maya
Of course, as soon as Maya gets released for OS X, I'm sure I could get ot illegally at all the usual places...
Pope
Freedom is Slavery! Ignorance is Strength! Monopolies offer Choice!
It doesn't mean much now, it's built for the future.
Can you back that claim up?
At the time that the IBM PC was being developed, there were only 3 possible choices for a 16-bit CPU: the iAPX86, the Z8000, and the 68K; the NS16K's didn't yet exist. At the time, Motorola's 68K sales force wouldn't lower themselves to talk to the designers of small computer systems; they insisted the 6809 (with a different sales force) was their solution in that market, although they changed their minds when they found themselves awash in 4-MHz 68000's about a year later. As for the Z8000... well...
In addition, IBM wanted to use an 8-bit bus. Remember, those were the days of through-hole components and "640K is more memory than anyone could ever need". The iAPX86 was available in an 8-bit version, the 8088; Motorola didn't even announce the 68008 until a year after the PC was introduced.
Certainly IBM has been known to intentionally cripple its products (the PC-Jr comes to mind), but the use of the iAPX86 architecture probably wasn't such a case.
>>>
these processors couldn't effectively be sped up beyond 100MHz, because of the amount of register-memory operations, unlike the x86 load into accumulator then do operation system, which has proven itself to be much more scalable
I don't think the issue was the architecture, it's just that companies were much more willing to support the enormous development efforts to extend the x86 than they were for the 68K. The techniques used in the Athlon to convert nasty x86 instructions into cleaner instructions for its RISC core could, theoretically, be applied to the 68K or any other ISA.
From day 1 there were better archetectures available, and at a lower cost. The only thing that kept it going in the early days was the market perception that PCs were business machines, so all the businesses bought them.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
no, cisc instructions are broken down into simpler ops by the microcode. cisc is the same as it's always been. yes, modern cisc chips have similar designs as risc chips, but that doesn't make cisc any more risc; it's just cuz they're modern designs.
IIRC x87 is the name for the floating point ISA originally presented in Intel's math coprocessor. And yes, the x87 ISA will be blown out of the water if you use the SSE2 floating point ISA in the upcoming Willamette (Ars as well as Ace's Hardware had pretty good articles about that a while back, too).
Light a fire for a man and he'll be warm for a day. Light a man on fire and he'll be warm for the rest of his life.
Intel is at least 8 years behind the curve; in fact, Intel hasn't been a technology leader since the 70s.
:-)). This is my all time favorite processor. It was both a general purpose processor and a 3D processor. It was super scalar, risc, pipelined, achieved almost 100 MFLOPs and >100MIPs in real applications with 50MHz clock. Programming optimized assembly for it was like solving puzzles :-). It came out about 1990.
I think Intel has/had great engineers, they mostly just do what they have to do to make much money: They improve and improve and improve the old technology in a compatible way. They showed us what they can do when they are "set free" with the I860 (please note the "0"
I often hear about the x86 being obsolete, old... but shouldn't it be the IBM compatible PC taht should be blamed?
Couldn't it be possible to do a x86 based computer that doesn't try to be compatible with the old IBM design or what evolved from it with all its IRQ (or the fact that there isn't enough IRQ's), it's bus and everything and use it (the X86) in a more modern design?
Isn't what VA Linux does for some of its boxes?
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
"For that you can thank Microsoft's amazing track record at porting to different platforms. "
Nt4 runs in Alpha, PowerPC, x86, and SGI (hardware atleast.. i know its a x86). Thats most of the major consumer cpus anyways.
SB.
no, it IS the cpu arch, but yes, it's also the pc arch. eg, pc bios.
DO you not understand that the 3DNow and MMX instructions are corrolated to hardware within the chip? To add MMX to the Pentium's Intel had to increase the size of the integer instruction unit. Telling your system not to include MMX would just shut down the MMX section of the IU. That is rather stupid. If you made a really simple RISC architecture with an emulation layer you'd get so much of a performance hit you'd be shooting yourself in the foot. Without any complex instruction units you're left with a Crusoe, and its already patented.
I'm a loner Dottie, a Rebel.
- From "Great Microprocessors of the Past and Present" (fascinating reading all the way through - check out the part about iAPX 432), we have "IBM's choice, the 8086". Read this on an empty stomach. It's fairly incredible.
- A note from the Usenet Oldnews archive - ucbvax.2667 - commentary contemporary to the imminent release of IBM's PC. Interesting mainly because of when it was written.
Sigh.. we could all have PowerPC machines if it wasn't for a funny turn of events.The 80x86 chips have been obsolete since they were first made. The only reason they got any part of the market over, say, Motorola chips was because:
1. They were US-made, so typical nationalist American bought it.
2. The early Microsoft wrote BASIC for it.
I always preferred the MC68000 chips.
(And no, I don't like Macs either.)
--------
"I already have all the latest software."
If we have to make an instruction set immortal why
couldn't it be something sensible like the PDP 11?
Need Mercedes parts ?
Not even that. All we have to do is apply multiple cycles of Phil's Law of Program Optimization:
- Every program can be made one byte smaller.
- Every program has at least one bug.
Conclusion: Every program can be optimized until it's only one byte long. But, it will be the wrong byte.That makes it a perfect match for your single-instruction x86.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
Much as I hate people who post definitions of words in /. comments, here goes.
obsolete (bs-lt, bs-lt)
adj.
1) No longer in use: an obsolete word. See Synonyms at old.
No. x86 is not obsolete.
2) Outmoded in design, style, or construction: an obsolete locomotive.
Yes, x86 is obsolete.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Ever play any games in the Quake series? They've got plenty of parts coded to the metal IIRC. There's one thing you're forgetting with the different architectures. Will my internal components be able to run? Sure my software can be compiled on x86, SPARC, or PPC but can I stick in my Soundblaster and have it work in said OS? Can I plug in my AGP video card and then stick in a driver CD and have it work all dandy? No I can't. Sure companies could write drivers for 20 different operating systems but why would they want to spend that sort of cash? If writing for different architectures meant different OSes they have to write OS specific drivers, or they can completely open their product specs which sort of defeats their patents which means there's no incentive to seel their product. The open sourced world is solcialistic in thinking that a money fairy is going to put clothes on their backs and heat their houses for them. You also need to remember that not all processors are equal, not everyone has the same operations. So if SoftwareA needs to use FunctionFoo and a SPARC or PPC doesn't have a FunctionFoo you're not going to have a very functional program.
I'm a loner Dottie, a Rebel.
When cosmic rays hit certain materials (metals especially) they cause a tiny nuclear fission which usually makes a charged alpha particle fly off. Alpha particles aren't too large but they can pack a wallop to very small electronics. The sort of electronics found in processors. If you have a very tight die with little space between components, there is a much large change of several of these being famboozled by a stray alpha particle. Wider dies mean if a single part of a circuit is taken out the unit as a whole can still work decently enough for your needs. Make yourself some effective radiaction screens and you can stick a brand new .13 micron processor inside and it will have a reasonable run aboard said spacecraft.
I'm a loner Dottie, a Rebel.
I think that the legacy of the x86 will continue long after x86 chips are dead. Right now, modern chips like the P6 and Athlon can already be considered to have a RISC-like core. In the future, exotic architectures like Transmeta's Crusoe may become common -- but they'll still be able to execute x86 instructions.
... MUL is DIV, ADD is SUB, SHR is SHL, Freedom is Slavery, War is Peace...
---
END OF LINE
It's a bit of both. RISC architectures try to make the instructions easy to decode, more like the microcode on a CISC architecture, if you've ever examined a CISC microcode listing. They also jettison complex instructions and addressing modes that take multiple cycles and screw up pipelines. The VAX POLY instruction is my favorite example. That doesn't stop them from adding a bunch of new, simple, easy to decode instructions.
Mea navis aericumbens anguillis abundat
The only think keeping x86 alive is the fact that if people tried to ditch it today, 90% of the world's desktop software wouldn't have anyplace to run tomorrow.
For that you can thank Microsoft's amazing track record at porting to different platforms.
Otherwise you wouldn't see so many companies trying to keep the architecture limping along.
--
Sheesh, evil *and* a jerk. -- Jade
REDUCED INSTRUCTION SET. YEY!
(Why do I see a -1 coming?) =P
Adding more registers is an issue the designers have. There's nothing to keep them from adding additional registers, except that they don't want to.
As for the segmented addressing scheme, try the extended registers (eax, ebx, and so on) and 32-bit mode programming. Works much better.
"22x faster with Multimedia than any other JVM!"
Don't believe everything they tell you. Since the introduction of hotspot there's nothing wrong with the execution speed of Java (check the recent story on Java performance, it's actually faster than C in some cases). The reason why java applications (graphical and multimedia in particular) are still slow is because of the way its libraries are implemented. Particularly Java2D and the swing classes are slow compared to their C/C++ counterparts. A faster interpreter does not help very much. In fact, the early swing implementations ran faster with the JIT disabled! So, unless tao completely reimplemented swing and other libraries, I'd be surprised if it performed significantly better than other JVMs.
I really liked the discussion in the article about obsolete and irrelevant. The real thing that has become obsolete is not the ISA but the static compiler that ties programs to it. The only reason x86 is still around is because there is no convenient way to convert an binary x86 program to, say an alpha binary, on the fly without performance loss. X86 will be around as long as people choose to statically compile their programs. The interesting question is not how long x86 will be around but how long hardware implementations of x86 will be around. Hardly anybody codes directly to an instruction set anymore. A simple recompile will port linux applications to other processors, often no changes are needed to the code. So, the dependency of the program to a specific ISA is not functional. In fact, as HP's dynamo shows, it is counter productive.
Transmeta's crusoe is the first of a generation of processors that can execute X86 efficiently without having a hardware implementation of it. My guess is that in five years or so, all major chip manufacturers will have stopped implementing instruction sets in hardware.
Java is ahead of its time in a way, since it is not dependent on specific instruction sets. The hotspot idea is not fundamentally different from what the crusoe does.
Jilles
I've programmed a variety of modern chips at a low level--MIPS, PPC, x86, SHx--and there's more to be said for the x86 than many people realize. For example, on a RISC chip, the subroutine call overhead can be stifling. Yes, it only takes a cycle or two to make the call, but then there's no hardware stack, so the return address has to be saved manually (usually two instructions to save it and two to restore) except for leaf functions. And then you may have to save 15 or more registers, at one instruction per, and restore them at the end of the routine. This all comes down to 20-40 instructions of overhead per subroutine. Is that progress? On the x86, subroutine calls are much faster and cleaner.
Also realize that all of these instructions are fixed at 32-bits on most chips. That's 32-bits to copy a register, 32-bits for a return, etc. This may simplify the hardware, but at the expense of bloat. So you need a bigger instruction cache.
Is the x86 perfect? No. If you look at an x86 reference, you'll find that over 50% of the instructions are either (1) really old things that mattered in the 1970s but not any more, like daa; (2) instructions from the 8086 and 80286 that run poorly on more recent chips, like lods and leave; (3) along the same lines, instructions for managing segment registers and other 16-bit relics; (4) MMX or Katmai related; (5) specialized instructions that we could easily live without, like the set family. If you take all of this out, you pretty much have a RISC chip. And you'd still be compatible with 95% of the code that runs on the Pentium II and III. I expect we'll be seeing this kind of thing soom from either Intel or AMD.
Geez, it's a 30 year old OS, there are tons of newer ones available that handle everything almost as well as *nix platforms do. It's time we got rid of this albatross and moved on.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
I am definitely not the same person as Signal 11. I don't know who Patrick Bateman is (never seen his posts before), so I don't know if I'm the same person as him.
--
Compaq dropping MAILWorks?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Beowulf?
Why do so many people misunderstand? it's not simply like having a 300 processor machine.
Fuck. Beowulf clusters != true cluster. A Beowulf is a really really dumb cluster that has no real hardware relation, merely a software relation over network cables. With a Beowulf a controlling computer gives all the nodes an algorithm or function and then gives them some data to perform the algorithm or function on. They perform said task and send their results to the controlling computer. A true cluster runs programs as if it were an SMP box. The Crusoe is NOT I REPEAT NOT SMP capable. This means it will not be showing up in true clusters, only Beowulf style setups that use embarassingly parallel computations. You'd be hard pressed to get a machine to turn programs that have only one thread or process into a program that had multiple threads or processes. The computer has no aware knowlege of what you're trying to get at with a function. All it nows is what you tell it. If you're going to tell it how to make your code be ulti-threaded you might as well just do it yourself.
I'm a loner Dottie, a Rebel.
They are a fab leader however, but the fabs could be used to make anything
Not to nitpick or anything, but I think it'd be more accurate to say that Intel is a fab capacity leader, not necessarily a fab technology leader. I think it's safe to say that IBM has a comfortable lead in CMOS fab technology for now.
Software shmoftware, how about the sournd card and video card that even let you use realplayer? In order for you to switch to an Alpha you'd need to find an Alpha mobo that works just dandy with your existing hardware and then drivers to make it all work on said new architecture. Software is a bit trivial at this point, its getting the sound card in my Linux box working that bothers me.
I'm a loner Dottie, a Rebel.
x86 has always been obsolete since the RISC technology has always been ahead of it
When the PPro came out its integer performance was faster than any RISC chip at the time. The G4 is about the same speed on integer ops in real life. x86 FPU is seriously fucked though.
Scuttlemonkey is a troll
As always, the Ars take on this (specifically, Hannibal's) is lucid and thoughtful,
;)
Just the other day I was reading about people's experiences when smoking marijuana. They say that it puts you into a state where you can think very clearly and intensely on a specific topic.
Are you alluding to something here?
Of course its dead. People still use it though, even myself: I just got a brand new AMD processor. Why? Because its a bitch to get the Alpha binaries for everything, that's why.
If you think you know what the hell is going on you're probably full of shit. -- Robert Anton Wilson
If you think you know what the hell is going on you're probably full of shit. -- Robert Anton Wilson
jdube is who
>He! I saw it with my own eyes! I tell you it is capable of running 3 versions of Quake and 2 versions of Doom simultaniously at full speed while hosted on Linux! Without an host (read Elate RTOS only) it will be even faster (up to two times as fast!)
I should add that this was done on a 500 mhz AMD K6-2. It used NO 3D hardware acceleration, all software!
I guess that if the architecture has become obsolete, it's time to get rid of my CBM 8086 system. Back in the days of DR-DOS, home-slice!
"I'm not even supposed to BE here today!"
> In any case, thanks for drawing attention to an interesting virtual machine. Diversity is a good thing.
Actually Sun currently busy advises all it clients to stop developing other JVMs and concentrate on this new technology instead.
QSSL (QNX) has made this decision some time ago. QSSL`s very competent coders were busy doing a good JVM implementation untill Tao showed them the light.
Read their announcement.
It is rather interesting that both Tao/Amiga and QSSL are members of a consortium called "The phoenx platform consortium" which goal is to produce a new Amiga-like operation system.
Way back in 1989 or 1990 I was taking a class in Assembler and the teacher was remarking that the x86 was making itself obsolete. IIRC, he said that the memory addressing was horrendous and the whole reason they stuck with it was for backwards-compatibility.
There comes a time when backwards-compatibility needs to be sacrificed for genuine improvement or development. Apple no longer supports the 68k series of processors, barely supports any PPC lower than a 604, and is moving strongly toward G3 (or G4) only. Mac users howled, but it was expensive and counterproductive to try to keep too much backwards compatibility. Use older OSes and older apps for older computers and let newer computers become truly cutting-edge. IMHO there's no need for gigahertz PIIIs or Athlons to be able to run WordStar.
Just my $0.02.----------
Something cleverWhat kind of question is that? Of COURSE x86 is obsolete. (Academically anyway). However, I really could care less if it is. It serves our purposes and we keep it around anyway. Academically, UNIX is obsolete too, better designs have already been made. Still, it work with the apps we have, it does its job decently, and that's why we continue to use it.
A deep unwavering belief is a sure sign you're missing something...
It can be bought online from amazon.com or an authorized dealer. It`s 99$ and you will get free support and a nice manual and free updates as the OS advances.
I always thought RISC meant reducing the complexity of each instruction, so every one could execute in 1 clock cycle. Not reducing the number of instructions.
Also, IBM was doing research on RISC in 1974, which predates the x86.
It's not trying to say "the x86 ISA is obsolete", far from it.
...but can't you do word processing 10 times faster on a 330 mhz machine than on a 33 mhz machine??
It's 10 PM. Do you know if you're un-American?
x86 is the architecture of the future! I mean, we already have the dual-CPU(x2) and quad-CPU(x4) motherboards that are getting ever more popular. I bet every self-respecting motherboard manufacturer is way ahead of that, and currently working on secret octohexal-CPU (x86) architecture! I bet! One other great thing about octohexal architecture is that it'll keep your room warm. See? x86's uprise has only just started!
G4 yes they are faster but in most cases run MACOS which is the and only operating system more useless then Windows. I didnt think it was possible but MACOS crashes all the time just like Windows and you have to re-boot almost as much.
"AH Shit i touch i better re-start my computer to be on the safe side"
My question is if backward compatibility is such an issue why don't the software manufactures port the software to the new platforms then we wouldn't slow down the hardware development. I'm sure if they wan't to Microsoft could port Office 2000 to the 64 bit platform just as easily as they port it to the Mac. Come on, software developers do the right thing...
Nathaniel P. Wilkerson
NPS Internet Solutions, LLC
www.npsis.com
Nathaniel P. Wilkerson
www.haidacarver.com
Yeah
RIS = set of reduced instructions, not fewer instructions. You could have as many instructions as allowed by the opcode field.
And I thought Pentium etc were just an extension of the same instruction set .
Anil Bhattacharji , anilbhx@sancharnet.in, Meerut Cantt. INDIA 91-121-642166
Macs have *always* had better backwards compatability than PCs, *especially* on the software side.
A recent PC can still run 15-year-old DOS programs. In fact you can still run one of the best DOS programs ever written, MS Works 2.0 (only 300K!), from the dark ages before MS became the master of bloatware.
I don't think any recent Macs can run 15-year-old Mac programs...
--
You think being a MIB is all voodoo mind control? You should see the paperwork!
A man who wants nothing is invincible
Is the x86 architecture obsolete? sure it is but theres so many of 'em out there or at least chips that bear as much resemblance to 'em as a Ferrari does to a VW bug but hey, they are both cars and you drive 'em in more or less the same way...
The issue of whether the design is dead or not will never be settled by the question "Is it obsolete?" but rather by "Does it still work?" The 486 and 386 should already have gone the way of the dodo by any standard of obsolesence but those two old boxes suit me very well thank you as a linux firewall and NFS server respectively. If they ever end up so short on power that they stop working in those roles then they will get upgraded but until then the upgrades are limited to the usual round of patch it, break it, patch it again :) Now admittedly I have no intention of using either as my main workstation (thats a K6,) but for as long as they do the job I need 'em to those older chips may be obsolete but they sure aint dead.
# human firmware exploit
# Word will insert into your optic buffer
# without bounds checking
I had a
Um, I think you're thinking of XFree86. This discussion is about the x86 family of CPUs.
---
Zardoz has spoken!
Oper on the Nightstar
Check out the Linux BIOS story from a couple of days ago. Made me decide to stick with x86 for a little while longer.
But technical obsolesence isn't really that relevent; the market factors governing success are really the presence of a transparent upgrade process, like Transmeta's Crusoe chip, for example. Something may be technically obsolete, but it is not socially or economically obsolete. Since we live in an economically governed society, not a technically governed one, the principles that affect the growth and distribution of new technology are economic, not technical.
Thus, we see x86 and DOS compatibility, two of the first and most popular (economically) primary personal computer architectures, resilient to even today. One might note that it is the presence of propietary technology that is indignant to change, and that open architectures (like ARPANet => Internet:TCP/IP) evolved dramatically. One can only speculate, of course, what would have happened if the internet was composed of closed minds and standards (and we can only agree to disagree at this time), or equivalently if DOS/x86 were developed by open minds with open standards in mind (again, only agree to disagree if you do).
So is x86 obsolete? Yes. But there is no clear economicly sound upgrade path at this time, but we are certainly seeing ones arise, especially with the advent of the internet and the universal movement "community", on that internet.
The technical expertise that lies behind the Athlon is amazing and shouldn't be knocked - considering all of the legacy limitations they have to work with, it's a real accomplishment that they've produced such a good chip. It's not the technology that's obsolete, it's what the technology is supposed to run that needs completely revamping.
---
Jon E. Erikson
Jon Erikson, IT guru
...it's either me forgetting my courses on processor (and ISA) architectures and construction or...
:).
:-/ )
I think they somewhat got the details a bit wrong on what an ISA is. Or maybe what they have in mind is what modern processors tend to be.
The ISA is (normally) the bottom-level instructions a certain processor can accept. Those instructions are then passed to the processor's instruction decoding unit and from there some parts of the instruction are passed to the arithmetic-and-logic unit (ALU) and some are passed to the address translation unit. So, the ISA is the really-bottom level language a certain CPU can recognise.
What happens in modern processors is that they are x86 *compatible*. They have their own ISA, but that is also compatible with the x86 ISA. I remember back in the days before the Athlon, when AMD was saying that the new processor (Athlon) will have its own instruction set AND will be compatible with the X86.
In other words you are (theoretically) capable of writing a program in Athlon-assembly that is incompatible with X86, especially if you can bypass the x86-to-native-ISA interface.
The way the K7 and the PIII work is they have a frontend that understands the x86 architecture and then they have the processor's own *proper* ISA that hopefully will sometime replace X86, whichever that may be. This is where the word "microcode" comes into play. Right now in your PIIIs / Athlons there is an extra layer of electronics that acts as an interface between your processor's native ISA (usually called "core" or "core ISA") and x86 ISA. This interface is the microcode. So, in fact, even now the K7/PIII are doing X86 *emulation*.
That, as you might have guessed, is a performance loss in its own virtue and hopefully will disappear sometime soon (along with x86
Anyway, hope this clears a couple of things. I'll probably write some more when I'm more lucid.
Trian
(arghhh, can't wait for the days when those Alphas will be affordable for the rest of us too...
I'm no longer fed up with MS Windows: I go rid of them
It's still the processor of choice for many satellites and even the International Space Station, specifically because of its dinosaur nature. Apparently space radiation makes the lastest (smallest) transistors prone to error, whereas the older chips can absorb it better and hence avoid a catastrophic error.
Well, I haven't read all of the comments...but after reading the article I'm left with one question. Who codes to the metal these days? I mean I'm going to go on a limb and guess that 95% of programs out there are written in something like C/C++ or Perl, where the metal is a non-issue. The cpu's aren't written to directly except by a compiler, and guess what - most code is somewhat portable between CPU's in a language (though maybe not between OS's). That being said, if I buy a new cpu who cares if it's x86 or not, since I can take a program, recompile, and there I am.
This is one feature I see as a benefit for open source and the rest. It makes the instruction set a non-issue. That's also one of the reasons I run linux/freebsd/openbsd (depending on which of my machines). Back when I was strictly a windows guy when I looked at computers to buy, it was x86 only. Now I have a choice between Sun, x86, hell even a (gasp) mac if I want. Why? Because I have that same code that I can recompile to run on the right OS on whatever hardware. Sure C code or whatever isn't going to pull as good speed as raw assembly in all cases, but if it means a CPU manufacturer can whip together a better cpu with a nice compiler, then who cares?
Maybe chip manufacturers should forget staying compliant to a single ISA and just give us better performance. It sucks for MS users, but for the rest of us I promise you an OS will soon follow, and with a recompile you're ready to go with all the apps you're used to.
Anyways, I'm rambling, so I'll shaddup now.
http://www.digital.com/amt/fx32/fx-r elnotes.html
Question: What ISA would you use if you were writing code that you knew would only ever be run on a processor like Crusoe? I don't think emulating a x86 would be the best way, but even emulating the best in the world is not going to be the perfect solution (assuming the code has to run as fast as possible).
I have always loathed the x86's bloody segmented architecture and arse-backwards way of doing things since day one.
The 68000 had a MUCH better architecture than the 8086 - nice linear memory space from 0 to as much as the memory bus could hold - bytes the right way round in long numbers - a delight to program for us old Hex hackers...
Had IBM chosen a 68000 processor, the history of personal computing would have been very different, and very probably a whole load better. Then again IBM deliberately knackered the PC design, so maybe they chose the inferior processor deliberately?
"Information wants to be paid"
How's this?
William Stallings lists four primary characteristics of the RISC architecture: One instruction per cycle, register-to-register operations, simple address modes, and simple instruction formats. With one simple instruction per machine cycle, CPU idle-time is significantly reduced. RISC instructions are hardwired into the chip as opposed to residing in a microcode ROM, theoretically reducing execution time by eliminating references to the microcode program as well as freeing up valuable chip space. Simple instructions greatly reduce the complexity of the chip, and eliminate such complications as performing an operation on several parameters while at the same time calculating effective memory addresses.
It doesn't say anything about the number of instructions.
1.Companies must stop supporting old architectures, regardless of the reaction of consumers.
That'll happen as soon as these "companies" decide that they're tired of making a profit. Nobody cares if you've got the best ISA on the planet (except /. readers). If consumers won't buy it, companies won't sell it. As long as x86 platforms can do what Joe Public needs them to do (Unreal), Joe isn't gonna buy anything else.
Nope. Try this one: http://slashdot.org/interview s/00/05/04/0821200.shtml - in my Ask Napster interview, I got a first post rated a #5, plus some comments about how cool that was. It still didn't do my Karma much good, which has now slipped to a low 32. fprintf
This post brought to you by your friendly neighborhood MBA.
> Don't believe everything they tell you.
He! I saw it with my own eyes! I tell you it is capable of running 3 versions of Quake and 2 versions of Doom simultaniously at full speed while hosted on Linux! Without an host (read Elate RTOS only) it will be even faster (up to two times as fast!)
> A faster interpreter does not help very much.
It is not an interpreter.(The JVM was totally rewritten in VP code) It uses some new translating technique. VP code is very compact and the translation happens in loadtime. The code is mostly smaller than the native code into which it will be translated! The translation is so fast that it can translate the code faster than it can be read for an harddrive.
> Java is ahead of its time in a way, since it is not dependent on specific instruction sets.
Sun has done a good job. But Tao is the real expert at this. In 1992 an Amiga assemble Games writter erected a new company upon his great new idea of an hardware independent OS. 8 years later his company is ready to revolutionize the computing industry.
Read this interesting article from 1994.
Ugh, very true. The Wintel combination has meant that each of them has held back to keep in line with the other, and because of this neither has been able to break away from the past.
Case in point - real mode. In real terms it has been obsolete since the 286 introduced protected mode and the 386 enhanced it. But it's only now with Windows Millenium and 2000 that real mode is no longer used by MS operating systems. This means that the chips require extra transistors for real mode and virtual 8086 mode making them more expensive and hotter, and Windows has reuqired extra code to handle legacy apps which use them.
No, you might have got a speed increase by changing the core from CISC to RISC, but you could also get one by just removing all the extraneous crap that's still there. Hopefully Intel or AMD will abandon their wish for every new chip to be able to pretend it is an 8086...
---
Jon E. Erikson
Jon Erikson, IT guru
If macs had old CLI programs, I'm sure they would be able to run them too (no interface issues to worry about).
As it stands, they currently run pretty much everything system 7 (1991) savvy and up, as well as possibly system 6 (1987) stuff. For the stuff before that, there are emulators for system 1 and 2 available if you really feel the urge...
just my blog and pix
x86 has always been obsolete since the RISC technology has always been ahead of it. It's just a favorite. Macs have, on a fundamental design level, faster processors. The G4's have been pulling a terraflop for a good time now. There are countless other processors that are just better than them. Their market share is just so large that they can sell them cheap, and they were smart enough to open the architecture.
Eh...
The x86 architecture has been obsolete for at least ten years. Then again, nothing in the Pentium2-class arena could be called an x86 by my definition; they've done some (admittedly) amazing stuff to keep hacking the speed higher and higher, determined to keep their precious cash cow from dying. The p3, by this time, is so different from the 8086 that thy're hardly the same ship or architecture. The only similarity is in the instruction set, and even then there are differences (let's see you run a KNI-enhanced program on an original 8086).
This said, the x86 instruction set really does have a lot of problems. This reflects the time in which it was made quite well. Very few chips made today have these problems; they've learned from x86's mistakes. Intel itself has hacked bits onto the x86 ISA for decades now, trying to patch up the problems, but they've also made the ISA a complete mess in doing this.
Does x86 have a performance limit? Theoretically, no; it's an instruction set, not a chip. But it's one hell of an instruction set to burden a processor with. IBM chose that chip for its PC line specifically to hobble it; that way the PC could never compete with IBM's then-profitable minicomputer line. This seems to have failed rather miserably, thanks to the amazing work done at Intel/AMD/etc. In time, x86 will die; every computing concept and program dies given enough time (anyone here still seriously use VisiCalc?) Frankly it is past its due; cleaner architectures have existed almost as long as x86 itself. But I suppose we should be patient. The day will come (probably when/if Intel finally gets IA-64 out the door).
As I thought you and others would probably doubt my words I searched the internet hard for evidence for my bold claims.It was difficult as it has been one of the best kept secrets.
Quote from ARM page "Because of the patented techniques, the intent JTE runs Java applications extremely quickly, more than 30 times faster than competitor's products."
Blimey! I just read the article and was amazed by the revelation on the third page that the VAX architecture was designed in 1757! That's nearly 100 years before Babbage's Differential Engine!
[Happosai]
No doubt they have a nice product but a 30x improvement, as mentioned in one of the posts, in performance sounds like marketing crap to me. In any case, I don't believe it until I see it.
Also note that their VM is about personal java, which is a slimmed down version of Java for embedded machines. Probably the competition uses an interpreter rather than a JIT to save on memory usage (this would explain the performance difference). No doubt speed is usefull in some situations but the real bottleneck of embedded machines is usually memory size. The more memory you have available, the more features you can put into the tiny space.
In any case, thanks for drawing attention to an interesting virtual machine. Diversity is a good thing.
Jilles
They do it in hardware, not in software: limited optimizations, no profiling of runtime system, fixed instruction set. There isn't a single transistor on the crusoe implementing a X86 instruction. It is all done in software. So, the crusoe doesn't have these limitations. The software that does the translation can be updated meaning that bugs in the translation can be fixed and bugs in the processor hardware can be worked around. New translations for new instruction sets can be added and most importantly it can do runtime optimizations using profiling information.
Jilles
The only reason why x86 processors are still developed despite its inferior archtecture is because of the many x86 applications available.
This is why Java will soon become the main language for programming applications. The only limitation stopping this development is the speed of Java code execution.
Now with the new technologies developed by Tao Group and Amiga Inc this disadvantage will bew eliminated. Their JVM is quote "22x faster with Multimedia than any other JVM!".
Sun Microsystems will advice all it`s clients to use their JVM instead! More info here
I believe it is generally understood that the x86 architecture is not the most superb set of instructions and such that we could get. RISC obviously has much value, the newer embedded systems and such will become more and more the wave of things to come. However, it's going to take some time. Here's what must happen before a new standard (whatever that is) is accepted:
- Companies must stop supporting old architectures, regardless of the reaction of consumers.
- Old hardware must die off, either broken or unable to run with any usefulness. My hobby is collecting vintage machines and making them run and do useful tasks. If I couldn't get them to run, I wouldn't use them. Period.
- Major business and educational software must be written primarily for those new architectures. You want Linux to be god? So do I. However, until most packages write their software for Linux, it won't happen. If things were written for the Amiga, I'd have an Amiga. Since things are mostly written for Win32, I have a Winblows box. (not that I enjoy the pain, you realize)
- Hype has to be mutated into standard. Sure, we all love to play with 1GHz Athlons, but are they standard yet? Hardly. Similar with other architectures. When a 64-bit processor becomes standard and not "the newest thing on the block since swiss cheese", it'll happen.
- Computer industry professionals (techies) and computer savvy people (geeks) must promote these new and alternate technologies. Break the mold. Go 64-bit. Recommend that your neighbor do it, too. Send a memo to your boss, tell them to convert. Until we push for this to happen, it won't.
In conclusion, this change will happen. When is a matter of many factors, including the ones above.Blog,Twitter
But obviously they haven't worked in the industry that actually provides CPUs and systems. ISA compatability is a do or die thing. Forcing people to recompile is an end-of-company decision.
Dismissing how important ISA compatability is in the computer industry today is simply an exercise in masturbation by kids who haven't spent enough time in the trenches.
...at least in the P6 and K6 cores. The CISC instructions are broken down into RISC ones to run through the 6 Intel/7 AMD pipelines.
-- LoonXTall
~~~LXT~~~
Life is like a computer program: anything that can't happen, will.
i beat you to it :)
2000-06-15 15:02:44 x86 Obsolete? (articles,hardware) (accepted)
strangely enough, it took almost 24 hours from acceptance to actually being posted. wierd.
---- I made the Kessel Run in under 11 parsecs.
There will always be advances in tech that will prolong the life of x86. There will always be an extension to the limit that will never be touched. The question should be When will the next device come out that will make throwing a few $1000 billion dollars worth of investment out the window feasible? I think this is the problem with all products. That and that damn least common denominator BS.
The x86 ISA has been closely married to the fate of a single operating system for quite some time now. After the shift from CLI to GUI, most of the compatibility issues in software have been WRT how to talk to the OS, not anything underlying. Nobody talks to the hard drive or keyboard directly--you talk to the driver. Likewise, the only programs that generally need to understand the underlying architecture are compilers.
There is so much standardization at levels above the processor instruction set that particular CPU architectures matter only while writing compilers and operating systems. Open source software distribution is making architectural irrelevancy even more thorough.
I will freely admit that there are applications which need good familiarity with the underlying hardware; most of these, however are drivers. The rest are heavily optimized scientific computing tools that need to bum every single instruction out of a loop because the loop is going to run sixty-nine trillion times.
As for the rest of the world, though, nearly transparant portability of operating systems and applications suites across architectures is a reality that lags only a few hours or days after the compiler is written. I'll offer two examples: Unix and Java.
When does compatibility with prehistoric applications become a reality? In places other than the x86 architecture. I do DBA work for an RBOC, and yes, we have ancient COBOL and FORTRAN applications that first ran in the 1960s. For those groups, Y2K was a genuine nightmare. But all those apps run on MVS and other mainframe environments--not exactly the x86's stomping grounds. As for other, pre-x86 micro architectures, well, I can run all my old Atari 400 apps under an emulator on my Pentium 200, because I have cycles to spare even to a badly written emulator.
So, no, the x86 isn't obsolete. The newer generations have some obsolete components, though.
--
This is not my sandwich.
What we lose in the x86 is performance. While I'm quite aware of the heroic measures taken by AMD, Intel, Transmeta, et al. to run x86 code quickly, you can't escape the fact that an optimizing compiler for x86 has extremely limited power of expression.
In computer architecture you want the ISA to be such that the compiler can do what compilers do best (static analyses over large regions) and hardware can do what it does best (dynamic adjustment to unpredictable runtime conditions). A bad ISA can bottleneck both the compiler and the hardware. x86 is poorly balanced in this regard. So's IA-64 (in the other direction), IMO.
On the plus side of the tradeoff, with x86 you get billions of dollars in fab R&D and commodity pricing, not to mention a huge installed base. It's never going to go away. Sigh. But life would be so much better for compiler writers, systems software people, and (indirectly!) users if all this business were centered around a nice 64-bit ISA rather than the x86 monstrosity. I very much enjoyed using the Alpha ISA on the Cray MPP machines and commend it as a model among the publically-known ISAs. No condition codes, delay slots, segments, special-purpose registers; just lots and lots of registers.
"Skill shows through where genius wears thin." -Wittgenstein || Religion: uniting aviation and architecture.
Duh! I mean come on, there's no contest between any x86 and say, the PowerPC or Alpha platform. Who needs to be able to compile 8080 code from 1977 on a 1 GHz Williamette. RISC, true RISC is the future, or at least should have been.
spoo
yes, because we still need to be able to play those great CGA games, like PARATROOPER (7ko). I loved this one. Great graphics, nearly true color graphics (white, cyan, magenta, black), incredible sounds on your pc speaker.
Recommended configuration: PC-XT with 8086 or 8088 4.77Mhz or better, CGA, MSDOS 1.x or better, 64Ko RAM, 5"1/4 floppy drive.
One thing that Ars fails to mention is that Dynamo only achieves performance at or below todays very advanced profiling compilers. Look at the graphs in the short form of the Dynamo paper: Dynamo Paper(short)
Dynamo also ignores a very important aspect of dynamic optimization/translation; the values of variables through each execution of the trace cache (i.e. exploiting common values of loop counters, function parameters, etc). A lot of researchers feel that this is the future of dynamic recompilation/optimization.
For a look at something more atune to value specific optimizations look at DyC
There are some links there to other dynamic compilation/translation sites too.
Don't forget that the research in this field is very new. There are countless possibilities to use runtime information to make a program go faster. People are trying to discover quick techniques for capturing this info and cheap, beneficial optimizations/transformations to apply.
The ARM chip has the most beautiful instruction set known to man - it really is breathtaking.
All those twats who said writing assembler on a RISC chip was `too hard' (babies) should try coding for the ARM. It's an absolute pleasure.
It's a pleasure.
arnald
Yes, but lost of people can't stand macs because they don't have any backwards compatibility. When I was going to buy my first computer I bought PC because I knew any Mac I bought would not only be obsolete when I bought it, also be unsupported by everyone - even Apple - within a few years. Plus Apple alters its hardware specs enough between models that you can't upgrade the hardware to get it compatible again... You just have to buy a new Mac after 3ish years. Its almost as bad as Microsoft really.
As for Mac users howling, you bet they did. When I told a guy I worked with that his 3 year old mac was too old to play a game he got for his young daughter he was pissed. He should be, by ditching compatibility like that it destroys any value his 3 year old computer had whatsoever.
So far I've gotten all my Karma from telling people they are wrong... :)
... will the next version be called x87 or y86?
Well, to overestimate the importance of code-size efficiency 200+ years ago is quite a tollerable error to me. ;)
Little-endian architecture is clearly much more elegant and the way of the future.
- My password is slashdot
The only way to play paratrooper is on an Apple II. Paratrooper rocks. IT ROCKS!!
My question is: will Crusoe, etc. be able to optimize in a SMP environ? AND even if it can do that, will it be able to do so for a COW or Beowulf cluster? It seems to me that such optimization at runtime might CRIPPLE a cluster if the processors weren't aware that they were clustered. OTOH, if they WERE aware, and could optimize parallel code, oooohhhh...... That gives me a warm fuzzy feelin just thinking about it. Whichever company achieves that,and it shouldn't be terribly difficult when you consider what they have done already on some of those projects, they could really leverage that. Especially if it optimized non-parallellized binaries to perform parallellized. Now something like that could revolutionize the industry. And give massive computing power. Amazing the level of technology we have achieved in so short a time... Our computers are not only self-aware(in a limited way, temp & voltage, etc.) but aware of thier surroundings(the code that they optimize.) So the next step is to make them aware of thier neighbors(other computers to help them crunch more efficiently and optimize for that). Soon they will be aware of us! Who is ready for that? Just some rambling thoughts...
Drop me a line at:
Key ID: 0x54D1D809
That's exactly what i'm asking..
We really should be throwing away most of the BIOS and filling it with useful things.
It seems the only reason it exists is so i can throw in my old DOS boot floppies and it'll function properly.
I don't care for that anymore. I have enough legacy machines that could run DOS if i so choose.. let's get on with it and evolve! =)
--
-=DaveHowe=-
While the x86 instruction set might be hairy, dumping it wouldn't make designing processors any simpler. Modern processors have so much complexity they are nearly impossible to understand in their entirety.
First off, they are all pipelined. So now you have all sorts of problems with branching. The good chips have branch prediction hardware. Then they have hardware to deal with missed predictions. Now there's hardware to take both branches and dump the incorrect result. Also, to the most speed out of pipelining, you need to reorder the instructions. So there's hardware to find read data dependancies, write data dependencies, and register dependancies. And if you branch, it's screwed.
They have an I cache and a D cache, so their's hardware to manage the translation between those, hardware to make sure reads and writes reflect the actual values, hardware to predict what needs to be loaded, and hardware to choose what's the best thing to throw out. And if you branch, it's screwed.
Not only are they pipelined, but they have multiple execution paths (at least an i path and an f path, but sometimes more than one). So you're issuing more than one instruction at a time, besides just pipelining it. Some paths can only take certian types of instructions. Some instructions requre the use of other execution units which are in limited supply. You have to add hardware to reorder the instructions to keep all of the paths full, otherwise you aren't squeezing enough performance out. And if you branch, it's screwed.
Now there's secondary and event tertiary levels of caching. So there's hardware to handle that. There's hardware to handle block access patterns, hardware to handle streaming access patterns, and hardware to figure out which of the two will give youthe best performance. There's even pipelined RAM. And if you branch, it's screwed.
You might bash the x86 ISA, but dumping it isn't a cure-all. In any case, the designers have been very clever. All of the nasty instructions that are almost never used and are hard for compilers to take advantage of have been getting slower and slower. Sure, the x86 has loads of instructions. But the ones that run really fast, and get used a lot by compilers, are mostly just the ones that you'd find in the most asture RISC ISAs.
Don't bash what works.
Damn... this has to be a /. record: Highest rated first post.
(maybe once long ago a first post got a 5, but I went out drinking last night so I can't remember anything before this morning, and hence it wouldn't count)
on topic: yes, RISC lovers have always sung the death of x86. Oh wait, I got RISC lovers and Sun Microsystems confused again...
While it is true that x86 *chips* continue to get faster and faster, the *architecture* does not. A variety of popular benchmarks consistently show that the efficiency (defined as performance/MHz) of the x86 has not improved *at all* since the introduction of the Pentium. In fact, it's gotten worse. Even the mighty Athlon is (depending on the benchmark) only a few % more efficient than Intel.
Compare that to PowerPC, Alpha, and some of the other RISC ISA families. Unlike x86, they actually *do* improve their efficiency as the family matures.
Case closed. The x86 ISA is stagnant. The *only* factor driving its continued performance improvement is increasing clock speed.
Once upon a time, Intel realized the x86 was a dead-end architecture and introduced the "432." That flopped, so we got the 286, 386, ... . What will happen if Itanium flops like the 432? Will we get the Icantium?
Well, you are correct, but some of the points also don't exactly capture the truth...
:P). Thus the only thing you save is code size, and a few extra words per function isn't really that big a deal.
:)
:)
It is true that your average RISC ISA requires quite a few operations to make a function call. However, you do _not_ have to save all 32 registers, unless you use all 32. You only have to save the ones you are going to use. Or, like in PPC, the function called is responsible for saving half of the regs (if it uses them), and the calling function half (it it wants to keep them). This helps minimize the number of loads and stores per function call. Most functions don't use 32 registers, so this works out nicely. My own code typically uses about 10-15 instructions total for this purpose. Larger (c-compiler generated) functions would use more, and thus have more insts for the stack, but this would be ammortized over the larger function itself.
Contrast this with x86, with it's hardware-managed stack. One instruction does it all for you. But that one instruction is going to get translated into a number of uOps - loads, stores, adds - that actually do the stack manipulation, and these take just as long each as the RISC equivalent. And because the hardware doesn't know what regs you are using, it has to save all of them (true, there are only 4 gpr's, but to view this as a plus in any sense is just wrong
Which is the next point - x86 and code bloat. Being variable-length, x86 can use the smallest number of bytes to represent an instruction. pop has one argument, so it can fit in one byte. Theoreticaly, this means smaller code, which means better cache utilization, which is a good thing. This is really the only good argument for a variable-length instruction set.
However, in practice, it doesn't quite work out that way. While some instructions are small, others are large. It turns out that with the mix of instructions compilers commonly use, the average code size of x86 is not substantially smaller than that of RISC-like machines. But the fact that the instructions are variable-length, and hence not aligned, means that things like cache-line splits over a single instruction are very common (the odds of an instruction's last byte hitting the cache line boundary are low). This reduces the effectiveness of the cache, since it can take multiple accesses just to get one instruction.
It is true that x86 has many many instructions, but that isn't what separates it from RISC-like ISA's. Look at PPC, which has nearly as many instructions as x86! I grant that RISC is a pretty vague term these days, but even if it only had 10 instructions, x86 wouldn't qualify. Two things that almost universaly describe RISC machines are: fixed-length instructions; memory accessed through ld and st only. x86 has a tendency to use the mem port multiple times in one instruction and other such variable-work oddities. the fact that add [eax], ebx (which, in uOps, is a load, an add, then a store) is a valid instruction makes x86 a non-RISC contender. Still, RISC is hard to define, which is why I like to call PPC RISC-like, or better yet post-RISC.
But you are completely correct right about one thing: you could take out most of those insts, especially the complex ones that use the mem port 42 times, and still run most of the code out there with no problem. x86 was defined before there were well-defined C compilers, so the designers didn't know what compilers liked (and decided to give them everything). It turns out compilers only like to use a very small number of insts.
While I highly doubt these useless insts will be removed from the isa of any machine claiming IA-32 compatability, they already are being pushed aside. On recent machines, the 'weird' instructions run very slowly, because they aren't just unoptomized - they're pushed into a corner and ordered to stay there because they've been bad. One thing you'll see is the unused instructions not being deoded directly at all, but instead simulated through an on-chip ROM that spits out the equivalent uCode at a slow rate. Decode is the bane and curse of all x86 chip designs, so why make it worse by decoding things that you'll never see?
Does this make x86 worse than RISC ISA's? Well, from a high-level language programmer standpoint, it really won't make much difference. The compilers generally spit out the same kinds of insts no matter what they are using. If you program assembly, you might hate x86 for only having 4(!!) GPR's, but like it for all the smooth, powerful instructions it gives you. But the problem is it's hard to know exactly how that inst is going to be translated into uOps, which means you run the risk of having that cool, smooth inst take ten times as long as you thought it would. *shrug* It's really a toss-up, and as current performance shows, neither post-RISC PPC nor IA-32 is obviously superior.
But from a chip architect or circuit designer standpoint, x86 is a damnable NIGHTMARE.
The enemies of Democracy are