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.
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.
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.
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.
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?)
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?
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
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.
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
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
...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)
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
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.
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 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?
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
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.
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 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.
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
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.
--
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 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.
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.
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
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.
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?
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.
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.
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
"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
Beowulf?
Why do so many people misunderstand? it's not simply like having a 300 processor machine.
When GCC is compiling, what exactly do you think it is compiling to? It isn't usually the bare metal, it is compiling to the ISA. And why the fuck would I want to recompile my software if I bought an upgraded CPU? Large programs with alot of linking take a while to compile even on fast processors which means I'd need to wait to actually do anything of important on my system. And then I'd have to compile all the programs I use. Do I really want to waste my time compiling everything (long live binary packaging!)? No I don't. The way to write directly to the metal of an Athlon is to write in Athlon assembler. Writing in assembler is fine and good and optimized if you're a good assembler programmer and the chip manufacturer doesn't change any of the chip components you're writing to. Do you realize how expensive it would be to write 30 different versions of Quake 3 or Office 2000 just to deal with a particular iteration of a processor?
I'm a loner Dottie, a Rebel.
To be fair to the Intel engineers, when the 80286 was being designed, real-mode was supposed to be a bootstrap into protected mode. The idea was that once you were in protected mode, you would stay there. The problem was that these decisions were being made years before the 80286 went into production, before there was a huge base of real-mode software (8086 assembler) that couldn't be easily modified to run in protected mode.
Mea navis aericumbens anguillis abundat
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.
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.
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...
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.
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!
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
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.
http://www.digital.com/amt/fx32/fx-r elnotes.html
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.
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
It isn't tough but it is time consuming. And gcc on some processors really blows. Take Linux on an Alpha for example. Using gcc programs run 20% slower than they do with the free compiler released by Compaq. The dude I was replying to wanted everything to be released as source with the end user having to compile everything. I'm not a big fan of compiling because I don't have the free time to sit for hours while my system compiles. Not only would you have to recompile 30 versions of Quake 3 but you would have to test and debug all those versions of it. Quake 3 also has alot of processor specific assembler to make it run a bit more efficently. You'd need more people coding for projects, ones that were gurus with a particular chip.
I'm a loner Dottie, a Rebel.
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).
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
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
If you think the P6 line is 32 bit, you are _extremely_ out of touch. The P6 has been doing 36 bit for several years. Perhaps you should check your facts in the future before you claim to know what is going on. Please log on to Intel's developer site (http://developer.intel.com) and get volumes 1-3 of the developer manuals.
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.
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... :)
--
-=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...
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
That's because the whole topic is clumsy, messy and convoluted. I thought he did a good job of laying out the background and discussing what is really a pretty complex topic.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."