Slashdot Log In
Is The x86 Obsolete?
Posted by
timothy
on Fri Jun 16, 2000 08:45 AM
from the will-we-conquer-death? dept.
from the will-we-conquer-death? dept.
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.
This discussion has been archived.
No new comments can be posted.
Is The x86 Obsolete?
|
Log In/Create an Account
| Top
| 336 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Address space is going to kill off the x86 (Score:3)
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.
Microcode (Score:3)
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
Re:A little premature to call it obsolete (Score:5)
Of Course (Score:4)
Re:Hyperbole. (Score:3)
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 a fully 64-bit system with a 200 MHz processor (faster than it sounds) and graphics faster than all but the high-end peecee offerings. Even Sun Ultra 2 systems, which are also fully 64-bit and offer dual CPU capability, are less than $3000 in reasonable configurations today, and it's even possible to get them new. You can say what you like about high workstation prices, but in the real world, clever individuals can get nice, if slightly out of date, systems that offer good to excellent performance for prices comparable with peecees.
On top of that, the only unix box hardware I really appreciate is SGI, but the only commercial unix I would run is Solaris - Which is a fundamental incompatibility.
That seems odd. Both SGI and Sun build great machines, but I'd rather put a fork in my eye than have to use Solaris. IRIX is ok most of the time though. IMO the only acceptable OS for Sun boxes is Linux. Try it; you'll like it.
Feel free to feel like you have a larger penis because you've left the PC platform
[Looks down] Looks pretty standard to me. A refusal to compromise with idiocy doesn't come from the penis, it comes from the brain, and I'm pretty sure ours are within 20% in size.
Until the cost of systems based on other processors drops
It has. See above.
the number of available applications must increase...
I don't know about you, but I have solid applications - we're talking about things that actually work reliably here - for every task I might possibly want to do on a Unix box. I challenge you to name a task I can't do on a Unix box. That Turd or whatever other flavor of the month isn't available isn't important - what matters is what tasks you can do, and how easily you can do them. I've found that Unix systems offer more applications than I could ever find a use for.
Reminded of what Torvalds said (Score:4)
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
A little premature to call it obsolete (Score:3)
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
Re:x86 is popular to hate, but not that bad really (Score:3)
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
What does obsolete mean? (Score:3)
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.
x86 is popular to hate, but not that bad really (Score:4)
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.
Is Unix Obsolete? (Score:3)
Back in school... (Score:5)
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.Read the article first! (Score:4)
It's not trying to say "the x86 ISA is obsolete", far from it.
x2, x4, x8......x86! (Score:4)
Obsolote Technology? (Score:4)
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.
Re:Windows again. (Score:3)
Agreed. However, the server market isn't quite so dependent on x86 compatibility (yet). Do the high end chips (Xeon, Itanium etc.) still contain the full instruction set, or have they dumped any of the legacy instructions that were only present to support backwards compatibility? After all, how many people actually run MS-DOS 2.x on a Xeon? My guess is that if they don't already do this, future generations of processors probably will, as extreme backwards compatibility becomes less important. Of course, Win2K could prove to be the wildcard here, as MS try to blur the boundaries between desktop and server. Yes, Linux does the same, but Linux has never had to run 16-bit code...
Time, Time, Time (Score:4)
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.Re:Hyperbole. (Score:5)
Did you, in fact, read the article? Hannibal said as much in his article. Obsolescence is the wrong question here; timothy [monkey.org] should be ashamed of himself for titling this Is The x86 Obsolete?.
Here's the short version for people too lazy to read the article or too dumb to understand what Hannibal is talking about:
Due to incredible amount of programs written for the x86 architecture, machines that execute x86 instructions will be around for some time yet. Everyone agrees (even Intel) that x86 is not a good ISA (instruction set architecture), but the ability to run all the programs written for it make it too costly to scrap. In order to achieve better and better performance, the current generation of microprocessors (Athlons and PIIIs) emulate x86 in hardware. The actual execution on these machines takes place using a completely different, RISC-style set of instructions (x86 being CISC for those who don't know).
This information addresses only half of Hannibal's article. The other and more interesting half describes the latest ideas computer architects have for circumventing the problems of the x86 ISA. The primary advancement is translation of x86 instructions into another architecture; this translation occurs only once, as opposed to emulation, and can be very aggressively optimized for the particular hardware it is running on because it is performed at runtime. Because the performance hit is only incurred once and because of the further, machine-specific optimizations, machines which execute x86 instructions will continue to increase in performance.
Furthermore, executing x86 instructions by translation means that computer architects have the freedom to change the native architecture of their machines without worrying about executing legacy code. These issues were addressed by emulation; translation is a further step in this direction.
As I said before, the obsolescence of the x86 ISA is a ridiculous and unanswerable question. However, I believe that the x86 ISA will continue to be a relevant problem until we leave 32 bit machines behind for 64 bit and larger.
Jonathan David Pearce
legacy code issue overrated (Score:5)
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.
--
Always a tradeoff (Score:3)
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.
Re:x86 is popular to hate, but not that bad really (Score:5)
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 really depends on your instruction mix. There are longer instructions on x86 too. And let's remember that simpler hardware means less die size, less heat, less power, and less cost. And remember that the SHx has 16-bit instructions, not 32. So on that architecture your code size will always be less than equivalent x86 code.
The bottom line is that x86 has about three orders of magnitude too many instructions and a similar factor too few registers. It exists without the grace of design or forethought. It's too big, too bloated, too hot, and more expensive than it needs to be. Programming it is a nightmare. The only positive thing I'll say for it is that the performance isn't terrible given its complete lack of design. This says good things about Intel's engineers. Of course, if they can do as well with x86, imagine how much better they could do with a decent architecture. In other words, if Intel manufactured MIPS and SPARC chips, they could crush the existing implementations in performance.
The x86 was obsolete 12 years ago. The sacrifice of sanity on the altar of backward compatibility is disgraceful and foolish. I don't use x86 any more, thank God. I just wish nobody else did either. We'd all be better off if x86 died the death immediately or sooner.
Optimal Paths and New ISAs (Score:3)
--