Slashdot Mirror
Despite Aging Design, x86 Still in Charge
An anonymous reader writes "The x86 chip architecture is still kicking, almost 30 years after it was first introduced. A News.com article looks into the reasons why we're not likely to see it phased out any time soon, and the history of a well-known instruction set architecture. 'Every time [there is a dramatic new requirement or change in the marketplace], whether it's the invention of the browser or low-cost network computers that were supposed to make PCs go away, the engineers behind x86 find a way to make it adapt to the situation. Is that a problem? Critics say x86 is saddled with the burden of supporting outdated features and software, and that improvements in energy efficiency and software development have been sacrificed to its legacy. And a comedian would say it all depends on what you think about disco.'"
It should be replaced with Esperanto when we all upgrade to Vista.
technical writing / development
I'm going to go with:
Did I miss anything?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The X86 ISA is a mess. It is a total pig. It is short on registers and it was just an unpleasant ISA to use from day one.
The problem is that it is a bloody fast and cheap pig that runs a ton of software and has billions or trillions of dollars invested in keeping it useful. I am afraid we are stuck with it. At least the X86-64 is a little better.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
The x86 instruction set will be retired in the same year as the QWERTY keyboard layout.
...using it right now.
Just like the four stroke engine. It's not the best one, it can be largely enhanced and made better, but it's still here.
And just like the four stroke engine, modern engines just burn gasoline and push car forward. This is where the similarity with the original engines end.
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
At this point, does it matter as much? As we move on the future is clearly x86-64 which is MASSIVELY cleaned up compared to x86 and is really rather clean compared to that. Sure at this point we still boot into 8086 mode and have to switch up to x86-64 but that's not that important, it only lasts a short while.
As we move off of x86 onto -64, are things really still that bad? Memory isn't segmented, you have like 32 different registers, you don't have operands tied to registers (all add instructions must use AX or something like that) as some 16/32 bit instructions were.
Of course, we should have used a nice clean architecture like 68k from the start, but that wasn't what was in the first IBM.... and we all know how things went from there.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
The architecture sucked when it was first introduced.
Just shows you what good marketing can accomplish with garbage.
---- Booth was a patriot ----
Yes, the instruction set is old, but, it does still work. As a consumer, why should I have to re-invest in software that I purchased and does the job, just becuase my hardware failed, or faster hardware becomes available and I upgrade. Apple bit that one some time ago. Last year, I had an investment of $4000.00 in software when Intel came out with a significantly faster part that was dropping in price. Just by upgrading my hardware (cost $800) my invenstment improved significantly. $4800.00 did not justify the upgrade but the low cost of hardware only, did. Also, there was not learning curve involved.
You don't buy a new car just becuase the tires need replaceing (well some people do, but that is rarely the fiscally responsible thing).
If it ain't broke, it doesn't need fixing.
Athiesm is a religion like not collecting stamps is a hobby.
Come the revolution, the x86 will be the first against the wall!! Eh.. maybe.
n /world-domination-201.html
Here's an paper by Eric S. Raymond describing his (and a couple friends) reasons for believing that there very much is a revolution in hardware coming soon to a technological infrastructure near you.. as soon as next year.
http://www.catb.org/~esr/writings/world-dominatio
It has been said that people will not change unless something is preceived to be 10 times better. The problem is nothing has been perceived to be that much better, so people stay with what they know.
Paul
Multilingual User Interface packs only come with Vista Ultimate. Oh, how I hate when a language strengthens monopoly power through such evil, costly means!
You can hold down the "B" button for continuous firing.
Things would be a lot easier if the darned thing wasn't so bloody complex to emulate. I mean if we were "stuck" with (say) an ARM or even a 68K we'd be able to use virtual machines to dig ourselves out of a similar architectural hole (though with an ARM we'd be unlikely to want to).
:-)
The x86 has so many modes of operation (SMM, real/protected, lots of choices for vectorizing instructions, 16/32/64 bit modes) and special cases that it's a pretty big project to get emulation working correctly (much less fast). You're pretty much stuck with a 10x reduction clock-for-clock on a host. Making an emulated environment secure is hard, too; you don't necessarily need specialized hardware here (e.g., specialized MMU mapping modes), but it helps.
And now, with transistor speeds bottoming-out, they want to go multicore and make *more* of the things, which is exactly the opposite direction that I want to go in...
Any sufficiently advanced technology is insufficiently documented.
If a chipmaker declared its chip could run only software written past some date such as 1990 or 1995, you would see a dramatic decrease in cost and power consumption, Crosby said. The problem is that deep inside Windows is code taken from the MS-DOS operating system of the early 1980s, and that code looks for certain instructions when it boots.
Even new software might (and often does) use the so-called old instructions. If you want to completely redesign the hardware you would also have to completely rewrite the software from scratch as you would not be able to rely on previously written code and libraries. This is simply not feasible on a global scale...
09 f9 11 02 9d 74 e3 5b d8 41 56 c5 63
Who is this guy and what is he smoking? Over half of a modern processor is cache. The instruction decoding and address decoding are a small fraction of the remainder. Where does he get the 60% from?
Sometimes I doubt your committment to SparkleMotion!
"Always forgive your enemies; nothing annoys them so much." - Oscar Wilde
I know we all bitch about old designs, legacy support for outdated features, but, one of the things that keep people from moving from one OS to another is "existing base of installed software" and "knowledge of exisiting software". Like it or not, the major player is Microsoft. No matter how much a geek says, MS UI's suck, people are comfy with them. If alternative OS's had the same software offerings with the same UI, people would be able to move to them. The same holds true for processors.
No matter how well a processor performs, if there is no application base for it, no one is going to buy a machine with that processor. In this case, perception is reality. You walk into a software store, you see 16 rows of Windows applications, half a row of Linux, and 5 rows of Apple.
What processor family runs each of these? Guess who has moved to the dominant processor?
The only way to build a software base is to build in legacy support. Then start weening users away from the legacy features, get programmers to stop using those features (mainly those building the compilers that developers use), and move towards the more advanced features.
x86 rules for a reason. Microsoft rules for a reason. The customer is comfortable with them, and their perception is reinforced everytime they go to the store.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
Since the legacy (DOS, 16-bit Windows) applications were designed to run on much slower computers, aren't we at the point where we can simply use software emulation of the CPU for those applications? Of course, for this to be commercially viable, Microsoft would need to do some substantial work and provide it as a free update for XP and Vista.
Unfortunately, that would only eliminate a small fraction of the baggage. And I can't honestly say I'd trust Microsoft to do it right. If I depended on legacy apps for my business I would probably want to stick with the hardware implementation.
Nevermind.
4. Price / performance. A segment the x86 have done well in.
:D
5. Security. Will my x86 progs be supported in 20 years? The answer: yes.
6. Availability. Hmm... Intel, I'd like to 1 000 000 CPUs. Intel: Sure thing.
7. Good will. What should we buy, Intel or PPC. PPC? What's that? Go Intel! Yes boss. (Just look how far Itanium got on Intel's name, alone.)
Actually, I suspect that this has far *more* to do with the money and far *less* to do with the technology. Commodity hardware is available to the home consumer for the first time ever. A quick jaunt out to some of the parts pricing web sites. RAM - PC2-8000 - 18 cents per MB. HDD - SATA II - 2 cents per MB of storage. Motherboards are cheap. Cases are cheap. However, if they start changing the system architecture they can talk all of us into buying new, high priced performance parts.
2 cents,
QueenB
HDGary secures my bank
... this is OLD news!
You know, there is a difference between trolling and pointing out the flaws in your reasoning. Just saying.
From the article:
:p
"There's no reason whatsoever why the Intel architecture remains so complex," said XenSource Chief Technology Officer Simon Crosby. "There's no reason why they couldn't ditch 60 percent of the transistors on the chip, most of which are for legacy modes."
(Emphasis mine)
Ehe, according to the latest in depth articles, the legacy cruft take less than 10% of the chip. A far cry from Crosby's claim of 60 percent, and that from a Chief Technology Officer no less
Boot loaders tend to be 16bit segment model code 8086, at least they contain enough code to get into 32bit mode. The BIOS will be 16bit legacy code, at least some anyway as a x86 PC chip still boots in Real Mode (there is a 386 embedded variant that doesn't). Windows 9x series is _RIDDLED_ with 16 bit code esp the display drivers, although many of these switch to 32bit mode ASAP the entry points are 16 bit code. Any attempt at killing off 16bit code would stop any 9X system running.
For WinNT and variants (2K, XP) I don't know how much 16bit code is in there. I've written drivers for 2K/XP and could not find a single 16bit style instruction however even NT series for x86 uses segments. FS is used for process & thread info. IIRC even AMD64 long mode implements FS & GS to make OS porting easier.
Lastly. 16bit code (instruction operating on 16bits of a 32bit register) are trivial in 32bit mode - all you have to do is preceed an instruction with 0x66 and/or 0x67 to switch a 32bit instruction to a 16bit instruction.
The problem transcends MSDOS and goes to the BIOS and boot sequence itself. Intel tried to address the with EFI but that seems to be slow gaining traction - probably because of backwards compatibility.
Time flies like an arrow. Fruit flies like a banana.
Computer manufacturers have tried making non-compatible machines. Commodore 64, VIC 20, Coleco Adam, Atari ST. They all had their place in time and their niche in the market before fading out.
Something they all had in common, though, is that they sold better than IBM's mostly-compatible PCjr. I attribute that difference to software and compatibility problems. Because of BIOS differences, a number of programs written for the PC couldn't run on the PCjr. That led to a fragmentation of shelf space at software retailers and confusion among retail customers, and led to customers avoiding the platform in favor of easier-to-understand options.
I would expect something similar to happen if Intel, AMD, or anyone else started making mostly-compatible x86 processors. It wouldn't sell unless all of the software people are used to running still worked. Sure, someone could take Transmeta's approach and emulate little-used functionality in firmware rather than continuing to implement everything in silicon, but it all pretty much needs to keep working, so why bother?
Seriously, why would anyone undertake the effort and expense needed to slim-down x86 processors when the potential gains are small and the market risk is pretty huge? No chip manufacturer wants to replace the math-challenged Pentium as the most recent mass-market processor to demonstrably not work right.
Pundits and nerds can talk all they want about why the x86 architecture should be put out to pasture, but it won't happen until a successor is available that can run Windows, OSX, and virtually all current software titles at acceptable speeds. At that seems pretty unlikely to happen on anything other than yet another generation of x86 chips.
Even RISC processors, like the fabled G5, have decode stages these days (i.e. translating instructions). I speculate that separating the inner workings of the CPU from the ISA simplifies the design somewhat.
In terms of volume shipments ARM and even Z80 sell _BILLIONS_. However margins are lower and the devices are either embedded or software compatibility is simply not an issue e.g. mobile phones where one uses the JVM or data is provided to an app and apps are recompiled per platform.
In terms of the PC - well, x86 is in charge and always will be. Without x86 a PC wouldn't really be a PC. Can one emulate/simulate x86? Yup, been done - especially well with FX!32. Is it more cost effective than just using x86? Not really.
Time flies like an arrow. Fruit flies like a banana.
You know, there is a difference between trolling and pointing out the flaws in your reasoning. Just saying.
And the Playstation 3, and the Wii, and your fridge...
It's The same reason people don't switch to Mac or linux, because there standard code will not work on something new. almost all popular software is written for the x86 arch, so if we upgrade, to say PPC, all the devs are going to have to rewrite there code, etc.
If free software ever goes truly mainstream, and the stacks people use are free from top to bottom, lock in goes away in general. Even hardware lock in.
A couple of years ago, I was shifting some stuff around and I needed to clean off my main desktop machine, an x86 box. I installed the same linux distro on a G4 mac and just copied my home directory over. Everything was exactly the same -- my browser bookmarks and stored passwords, my email, my office docs, etc.
A lot of people take Apple's jump from PowerPC to x86 as a sign that x86 is unstoppable. But I'd argue that the comparative ease with which the migration took place shows how weak processor lock in is becoming. The shift from PPC to x86 was nothing compared to the jump from MacOS Classic to OS X.
The real reason x86 won't go away any time soon is that MS has decided that's the only thing it's going to support, and MS powers most of the computers in the world. Windows is closed, so MS's decision on this is final, and impossible to appeal.
www.engrish.com
'nuff said.
/\/\icro/\/\uncher
I would add to this that ISA mattered a lot more when I wrote code in assembly language. For a clean (and simple) instruction set architecture, I fondly remember the PDP-11. Later on, the 680x0 offered more powerful addressing modes for less simplicity (and consistency). Compared to both, the x86 was infuriating to work with.
ISA's still mattered, but less, in my early "C" days when source-level debugging was less robust, or even to understand what the compiler was turning my code into so I could figure out where to optimize.
Today, it hardly matters at all. Looking at generated code tells me little about how the processor with multiple execution units is going to process it; it is necessary to trust the compiler and its optimization strategy. It matters even less with interpreted or JIT'd languages, where the work eventually performed by the processor is far removed from my code. Knowing what's happening at runtime involves much more important factors than the ISA.
A little off-topic:
I've had a picture of a die for my desktop wallpaper for a while now, and I think it works well. I'd really like some larger pictures of the dies they give here. Does anyone know where I would find larger ones?
// MD_Update(&m,buf,j);
As part of an operating systems course I am currently taking, we watched a video of a presenter from Intel who lectured on the changes associated with the Itanium processor. In his presentation (see the video at http://online.stanford.edu/courses/ee380/040218-ee 380-100.asx), he pointed out that Intel has gone from having one or two major ideas to drive chip design to having fifteen or twenty minor ideas that they can cram in. The thinking is that if they can amass enough of these "little ideas" together, they can probably cobble together enough performance enhancement to justify production and sales of these chips. Part of the issue is that, as the author of this article also admits, there is currently no "big ideas" coming around the bend in terms of truly revolutionary performance increase.
The problem, though, is that when you introduce many smaller features, you cannot always anticipate how these features will interact with one another. This is why it is counterintuitive to many people that "new and improved" is not always so, and that you actually risk introducing bugs into the design more subtle than you can detect. That, combined with the continuing support for legacy code, means that complexity (and power consumption) goes through the roof with each iteration. While it is a testament of the robustness and versatility of the x86 architecture that it has survived thus far, one could argue that the architecture *had* to survive because we couldn't come up with the next paradigm shift.
The good news is that there are solutions to this situation. The bad news is that all of the solutions involve massive change in the way the software industry clings to the tried-and-true, or truly revolutionary innovation in chip re-architecture, or billions of dollars, etc. As the article points out, experience with EPIC has demonstrated how NOT to introduce a completely new architecture. There is no easy way out, but there are several possible paths.
Installed Base...
Best Slashdot Co
The article claims that Windows still requires the old compatibility modes to boot. Is this true? I could see how Win95-like OS's could because they basically boot on DOS. But, for NT and beyond, wouldn't they be fine with removing those old legacy capabilities?
The question that leads to is: What is gained by removing the legacy junk? The guy from Xen-Source in the article claimed "There's no reason why they couldn't ditch 60 percent of the transistors on the chip, most of which are for legacy modes." Which seems ridiculous. Maybe he's talking about 60% of the silicon in a certain subsystem of the CPU, because it certainly can't remove 60% of the total transistors.
If the savings is minimal, and those modes don't effect anything once you've changed to 32 or 64 bit protected mode, then maybe it's a moot point.
To really shift the Instruction Set, you obviously have to do it in an evolutionary way. Such as, allowing access to the lower level IS (i.e. the instructions that the x86 gets translated into) in a virtual machine environment. So, you could have a more efficient Linux OS running in a VM, and if the benefits of that are substantial, more people might use that mode for the host OS (which could then run x86 VMs for legacy). It's easy to see that being used for Linux and even Mac OS as their portability is already proven, and they began as modern OS's - working only in protected mode.
We lose the X86 when another processor comes along that is cheaper, 10x more powerful, and runs all X86 software at the speed that the users consider to be the same as a PC. Until then we keep the X86. Simple as that. Next tech issue, please.
Amd64 isn't much better: I want more than one bloody stack pointer, thanks. Is there some sort of shortage?
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
So I took a walk this evening, actually while visiting family. We cruise on past this house in a nearby neighborhood and then stop, because I've backtracked. Next to the trash can is a Dell computer. I think, how bad can it be? And take it home. Older processor, dead hard drive, monitor with a bad cap causing intermittent screwups. The only part not fixed is the monitor, but I dropped in an old IDE drive and it's a perfect FreeBSD machine. Heck, if I had the bandwidth at home, I'd serve my website off of it.
The Linux box came from three or four older computers, two of which belonged to me, combined in the least-junky case I could find. I'm still not certain of which distro will be "final" on it, but I'm trying Ubuntu now. This machine gets re-imaged at least once a week, because it's the "beater" box for experiments.
I've also got a Windows XP machine that I love dearly. It's an Intel board, a 2.4ghz P4, some other stuff I forgot. I put it together for $600 and it's more stable than the Windows machines my neighbors bought from Dell. I have no plans to upgrade to Vista for another two or three years, for the largest part because I don't want to buy the hardware.
Life rewards intelligence if you're willing to apply it. Is this hacking, best practices, or common sense? I also get free jalapeno peppers from a very small garden, if I remember to water it. No "corporate chilis" for me. Linus would be proud.
technical writing / development
Comment removed based on user account deletion
The irony of being a grammar Nazi by pointing out that the statement "People like you make Nazi's look good." is incorrect. It should be "People like you make Nazis look good." - unless there is some unseen object that the Nazis posses, the apostrophe before the "s" is unnecessary and incorrect. Simply adding a "s" to the end is sufficient to make it plural.
"But this one goes to 11!"
80x86 code can be compiled on the fly to native code, just like Java bytecode, and then be as fast as the native platform (minus the really low level optimization tricks lost in the translation, of course).
The Instruction Set of a processor architecture with so many resources available to it doesn't really matter, so long as it isn't utterly and completely braindead. X86 isn't braindead enough to qualify... if you had an intercal instruction set or an One Instruction Set Computer it might.
You really want to do several things to get performance out of an instruction stream -- register renaming, instruction manipulation (breaking them apart or joining them together or changing them into other instructions), elimination of some bad instruction choices, and a host of other things. You would want to do these things even on a "clean" ISA like Alpha or PPC or MIPS. And if you are doing them, the x86 instruction set suddenly becomes much less of a problem. There are even advantages: the code size on x86 tends to be better than a 32-bits-per-instruction architecture.
Instruction sets are languages with exact meanings. Which means that you can precisely translate from one instruction set to another. And, as it turns out, you can do it fairly easily and efficiently. Which is why Transmeta did pretty well. Which is why Apple's rosetta and Java JIT compilers work (and Alpha FX32 before that). Which is why AMD and Intel are right there at the top of the performance curve with x86-style instruction sets, because it JUST DOESN'T MATTER THAT MUCH.
Why didn't Transmeta kick more butt? Because they didn't have the economies of scale that AMD and Intel have. Because they didn't have the design resources that AMD and intel have. Because AMD and Intel had better-tuned processes faster than TSMC or whoever was fabbing Transmeta's chips. THOSE are the most important things, not the instruction set that you have on disk.
Now a good ISA can help in many ways: SIMD instructions really help to point out data level parallelism. More registers helps a wee bit to prevent unnecessary work done around the stack for correctness. You can get rid of a bit of logic if you can execute without translation. But these things can either be added to x86 (SSE/x86-64) or aren't expensive enough to be worth it on a 100 sq mm, >50W processor. Maybe in an embedded, low-power processor.
-- Erich
Slashdot reader since 1997
We should of course try to improve CPU ISA, but actually most crappy software results from horribly coded business logic. Ok, the ISA matters for things like graphics and optimal high end scientific computing (but those may be already on a specialized ISAs). But for the home user, their slowdowns arise from crappy coding .. not the CPU's ISA.
Most often, we're victims of crappily coded business logic and programs that don't follow good software engineering practices. If the benefit from an optimal ISA could squeeze out a 2 - 3x speedup in running time or CPU cost reduction, but the benefit from good coding practices is 10x - 200x (especially for some of the database stuff -- combined horror caused by terrible db schema design + nasty SQL queries).
Sorry had to vent that off.
but its installed base is so large that it is really hard to convince people to switch.
This is the same idiotic argument as always. They don't even try to change it up a little bit...
The architectural limitations of x86 were probably true up through the Pentium1 days. After the introduction of Intel's P6, and AMD's K6, everything changed. At that point, x86 was no longer the clumsy CISC snail it used-to be. At that point, and from then on, the fierce competition between Intel and AMD has pushed x86 ahead of every other architecture. Others like Alpha held on to the pure performance crown for a few years to come, but they did so by embracing much higher power consumption. These days, new x86 CPUs are falling in power consumption, not rising. And AMD's Geode CPUs can give you a good performing x86 CPU for embedded systems, OLPC, and anything else, in under 1W. There's really nothing else that is lower power, which still performs as well...
These days, x86 is more than competitive with everything else in sheer performance, performance-per-watt figures, and far ahead in performance per dollar. One at a time, nearly all the limitations of the x86 architecture, that were so often paraded out by competitors, have been worked around. It's most other architectures which were crippled, in that their short-sighted design was only really good in one area, and they only became popular because x86 wasn't quite there at the time. Meanwhile, x86 continued to develop, addressing those shortcomings, and the others did not. The only competitors these days are Power and SPARC, and the two highest-profile companies using them have long since come around, and started selling x86 themselves.
Backwards compatibility is only the smallest of reasons that x86 is still around. How many Linux/BSD users continue to buy x86 systems, even though they would hardly notice an underlying architecture change? How many super-computing clusters are x86-based? It's only the Windows world that needs x86 compatibility, and though that's about 90% of the market, the other 10% use x86 anyhow.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Developers,
Developers,
Developers!
Why? Because it has strong competition going on.
Ever since AMD64 technology, it isn't that bad either.
When are they going to fix bufferoverflows and stack exploits. Something in the hardware that prevents a process writing out of its allocated memory. Something in the hardware that marks pages read/write or execute and prevents code being executed on the stack.
davecb5620@gmail.com
A paranoid aquaintance of mine keeps saying that one of the reasons x86 is so used is because there are undocumented instructions in it to allow ring 3 code to run as ring 0. He ranted on about the F0 0F bug, and sticks to his claims that there are other instructions similar to that.
The linked article says that people kept Windows 3.0 around because they liked playing Solitaire. Yeah, right. It's undoubtedly true that lots of businesses ended up paying their clerical workers for many hours of time spent playing Solitaire and Minesweeper, but that's a symptom, not the cause. The real Windows 3.x killer app/feature was multitasking. The fact that you _could_ play games without closing the spreadsheet or memo you were working on was huge. Multi-tasking is what sold Windows 3.x. For the first time, you didn't need to stop one thing to start another.
Meanwhile, the killer feature for Windows 95/98/etc. was the native tcp stack, which enabled everyone and their brother to get email accounts. Suddenly, businesses were paying their clerical workers to gossip, spread urban legends, and exchange South Park videos with one another.
Want to get Linux adopted by more end users? Figure out what the next, hot form of wasting time at work will be, and make the experience better on Linux than other platforms.
> So take your Vista turd and fuck yourself. Asshole.
Yes, a typical Linux fanboy reaction, just as I was expecting. Thanks for proving my point.
I'll probably be modded down for this...
Yes, I totally agree. English should be replaced with Esperanto, for Esperanto is a much simpler, better structured and more logical language. One could learn Esperanto grammar in several hours or so.
The problem with English is completely moronic, retarded phonetics and dumb, unnecessarily complex tense system.
...rather than intelligent design.
"How to Do Nothing," kids activities, back in print!
> Now, this is the important part: He's used to XP. He's used to an OS, that while sucky, worked well enough for him, was relatively speedy, so why can't he just have that? Why does he have to have something replaced that worked just to put up with this shit?
If instead of giving up after a day, he had tried it for a week or a month, he would have found out how great everything is. Then in a few months he would be used to it and if you try to make him downgrade to XP he will cry.
There are many great features in Vista, but you have to try it for yourself.
I'll probably be modded down for this...
x86 may persist in desktops but it is probably already vastly outnumbered by ARM instruction-set chips in phones.
They probably won't make you use your PC less but there are a lot of people who don't have computers and may never get them because a handheld will be good enough.
This is all just my personal opinion.
You note made me wonder: could you jokingly say there is 1-bit legacy code in every computer? Acting on an input from the user, the on/off button code initiates the 16bit code.
The world is made by those who show up for the job.
Sometimes it's support and marketing that make all the difference. Way back when, IBM introduced a new computer called System /360. It was crude compared
to a lot of its competition, but they knew how to sell them, and they
supported them well. IBM went on the rule the mainframe world. Their
competition are now footnotes in history books.
One of IBM's competitors gave us the phrase "Sullen but unrebellious" to describe how much money must be spent looking after customers.
I play with Linux on UltraSPARC (Sun Ultra 5) and StrongARM (gumstix) but am typing this on an x86 Slackware box. Does this mean I too have sold out? :-)
...laura
Open Source pornography? Some of you nerds must have girlfriends who aren't camera shy.
technical writing / development
I get your drift but if Intel had a good ISA then we wouldn't need those damn compilers.
Okay, that's perhaps a bit over the top.
Rotary with it's wear and consumption issues?
Miller-cycle which requires a supercharger?
Surely not two-stroke with all pollution...
Turbine? In a car?
Not sure what your point is.
Blar.
The x86 instruction set doesn't need to be replaced. We're approaching the ceiling of what performance you can squeeze out of a single general purpose core anyway. Some years ago some people figured out that a special purpose processor could beat the living crap out of a standard CPU in terms of rendering graphics, and today there are virtually no games relying on the CPU for that anymore. We even have physics accelerator cards now, and the Cell microprocessor follows a similar principle. So, I believe the x86 instruction set will still live 10 years from today, but in musical terms I believe it will continue towards the role of becoming the "conductor", and away from being the "musician". I wouldn't be surprised if Intel or AMD at some point releases a CPU similar in design to the Cell processor (with PowerPC replaced by x86).
Much like Microsoft.
What's with all this dissing of the X86?
Like you, I'm an old fart; I wrote assembler code for the PDP-8, PDP/LSI-11 and the 68k. They were ok: easy to learn and use, but I always preferred the X86.
Sure, it was harder to learn and I never got past having the blue book on my desk when I was coding but, in the end, it produced smaller, faster code. There were a number of apps I wrote for multiple platforms, so I got to compare. Also, (the same reason I love perl) you could do astounding things with side-effects.
Commercially, X86 has staying power because it was architected to scale. Variable-length instructions with lots of space in the operator range lets Intel adapt the design to any new demands. Most, if not all, of the complaints about X86 (e.g. too few registers) are just version features—yesterday's news if there's a market demand for an improvement.
Bottom line—it ain't neat, but that doesn't matter; it's programmed once and used millions of times. Programmer convenience is irrelevant.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
I tried looking into my heart but it asked me to "allow" or "deny". When I hit "allow" I got a BSOD. I'll have to get back to you on that one.
Would it be possible to make a legacy free x86 chip? i.e. remove from the processor die real, unreal, VM86, and 16-bit protect modes as well as all traces of the ISA bus, the BIOS, and anything else you can think of? Porting *NIX and Windows to this new platform architecture would be effortless and it would not change userland compatibility.
We don't need to support 30 years of backwards compatibility!
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
The x86 instruction set is a surprisingly good way to build a computer. The reasons aren't obvious.
First, the original x86 was a huge pain, with that stupid segmented memory arrangement. But IA-32 was better and cleaner; at last there was a flat 32-bit address space. (Yes, there's a segmented 48-bit mode, and Linux even supports it, but at least apps see a flat address space.) AMD-64 is even more regular; the segmented memory stuff is completely gone in 64 bit mode. So there is progress.
RISC architectures could yield simple machines that could execute one simple fixed-width instruction per clock cycle. The early DEC Alphas, the MIPS machines, and early IBM Power chips are examples of straightforward RISC machines. This looked like a big win. The ALU was simple, design teams were small (one midrange MIPS CPU was designed by about six people), and debugging wasn't hard. RISC looked like the future around 1990.
What really changed everything was advanced superscalar architecture. The Pentium Pro, which could execute significantly more than one instruction per clock, changed everything. The complexity was appallingly high, far beyond that of supercomputers. The design teams required were huge; Intel peaked somewhere around 3000 people on that project. But it worked. All the clever stuff, like the "retirement unit" actually worked. Even the horrible cases, like code that stored into instructions just ahead of execution, worked. It was possible to beat the RISC machines without changing the software.
The Pentium Pro was a bit ahead of the available fab technology. It required a multi-chip module, and was expensive to make. But soon fab caught up with architecture, and the result was the Pentium II and III, which delivered this technology to the masses. Then AMD figured out how to do superscalar x86, too, using different approaches than Intel had taken.
The RISC CPUs went superscalar too. But they lost simplicity when they did. One of the big RISC ideas was to have many, many programmer-visible registers and do as much as possible register-to-register. But superscalar technology used register renaming, where the CPU has more internal registers than the programmer sees. The effect is that references to locations near the top of the stack are as efficient as register references. Once the CPU has that capability, all those programmer-visible registers don't help performance.
Making all the instructions the same size, as in most RISC machines, leads to code bloat. Look at RISC code in hex, and you'll see that the middle third of most instructions is zero. Not only does this eat up RAM, it eats up memory and cache bandwidth, which is today's scarce resource. Fixed size instructions simplify instruction decode, but that doesn't really affect performance all that much. So x86, which is a rather compact code representation, actually turns out to be useful.
You say that to be funny, and it is, but it's also insightful.
One of the things about evolution is that it can only work with what it has, which is why our backs hurt all the time. Evolution can't just suddenly stick a good spine/leg support/locomotion system in, but works with what already exists, intended for quadrupeds. (This is, in essence, the area that the Irreducible Complexity crowd are attacking.)
But, look at x86 and its dominance over itanium. Itanium is a *good* design, but x86 is outcompeting the hell out of it because with a kludge here and a workaround there, it could be iteratively fixed up to outperform itanium. x86 has evolved to be the top dog despite going up against intelligent design of the itanium, showing that the criteria for success aren't always what we think they are.
Nostalgia's not what it used to be.
Applicaton software is the main drag anchor that ties us to the x86, and currently a lot of stuff is still C/C++ compiled down to bare-metal machine code.
I'd guess that long term, more and more software will run as bytecode for a virtual machine, or in a scripting language of some type. Look how much already works that way: Java, Flash, AJAX, .Net, "LAMP". Then you have code translators and emulators like Rosetta on the mac for legacy apps.
If these start to consolidate a bit (e.g. if Google takes over the world and everything goes AJAX) then, rather than a new platform needing a critical mass of applications to be ported individually to be viable, all you need to port would be a kernel and half-a-dozen virtual machines.
Of course, that doesn't overcome the massive "sticktion" of the x86 installed base.
In a sense, that's already happening - in hardware - as post-586 Intel chips are effectively a "RISC*" core with a (hardware) translator turning x86 code into core instructions.
* the term RISC is getting less applicable as more specialist bolt-ons for vector/multimedia work get added.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
Why did it have to be a little endian processor?
In the course of every project, it will become necessary to shoot the scientists and begin production.
Seriously you must be new here for the "I'll get moderated down for this but..." trick is one of the PRIME Karma Whoring mantras. Simply by inserting it into your statement you can not only be granted immunity to downmodding by fanboys but you just might get some positive modding by the choir to whom you are a preachin'. Sadly it is also needed in this day and age of the rabid fanboy as sort of a garlic/crucifix/holy water shield agaunst said fanboys simply to keep your karma at a decent level. I know, I post this AC since my karma has been terrible for over 6 years now because of an incident with some Mac fanboys. I've never been modded badly since and the good mods I did get have never restored my karma to a positive level. Had I simply added "The Mac asshats will probably mod me down for this but..." I would probably have my perfect karma that I did so long ago. So that's my pitiful story...mod me down if you must ;)
First Intel tried to replace the architecture at least three times resulting in expensive commercial losses.
Second, since 486, the Intel has been RISC at core and merely emulates the old instruction set. The amount of transistors need to do this shrinks proportionately each generation. I think the emulations is less than one percent of the real estate currently.
"60% of the transistors on the chip" != "60% of the chip are transistors".
When you see it, you'll shit bricks.
I rescued a little 5 year old Shuttle barebones system this weekend that had been on ice a few years because of its habit of freezing up unpredictably.
Now I have a nice little headless server with an Ubuntu OS, LAMP stack, Tomcat, etc., and the freezing problem seems to be gone (I'm hoping it was either XP or the video card, since both got removed). And at this point I'm like the apocryphal dog that catches the car and doesn't know what to do with it.
I don't yet trust this thing enough to use it as a file server or for storing anything important, I can set up a personal web site anywhere, I don't need a proxy for surfing porn sites at work, I don't play video games or need a game server, and it's hot with loud fans even by 2002 standards so I don't want to leave it on all the time for no good reason. I'd be responsible for an iceberg calving off a glacier somewhere. I already get a mental image of Al Gore every time I hear it start up. All the other computers around here- laptops of more recent vintage- are quietly running more modern, efficient, and powerful (x86-based) processors and they really put this thing to shame. But, they are not stationary.
I'm trying to think of a nice little web programming side project- something fun to sharpen the skillz not being gained at work- that wouldn't kill a 5 year old AMD 2000 processor or saturate a crappy ASDL cable connection (at least for a little while), but that would still be interesting enough to justify the electric bill. Mailinator for example would have been a good idea. That guy set the whole thing up on a box just like this. I hate seeing cool things I could have done.
This article is somewhat misleading in a sense. Not such a hugely significant proportion of transistors are now committed to legacy modes. In fact, the most significant proportion of the transistor budget is spent heavily on cache, not backward compatibility. The problem with x86 is the weird addressing modes, the strange dependencies on using particular registers with particular instructions, the absolutely horrible FPU, a general lack of registers, and the need for more complicated instruction decoding logic for the variable length instruction format. Also, there are probably many instructions that no compiler ever uses in generated code. I am sure that the implementation of these has already been moved to microcode, and there is little significant logic consumed by the continued presence of these historical dead ends.
The FPU has been largely fixed with SSE / flat register model. The lack of registers is less of a problem in long mode with the increase in number of general purpose registers, the variable instruction length format may actually be beneficial? although it costs some logic, it can make simpler instructions use fewer bytes, such that they consume less memory/bus bandwidth - a measurable gain, or just wishful thinking? The dependencies on particular registers for particular instructions, I'm not sure about? has anyone got experience with long mode programming? is this still a problem?
There are things that could be killed like virtual x86 mode. Who wants to run DOS programs on windows anyway? It shouldn't break anything worth having to kill that.
Also, current x86 architectures can't really address very large amounts of memory. If you need a machine with decent amounts of RAM for serious number crunching, it has to be Itanium or maybe POWER. The best x86-64 boards (Supermicro etc.) only usually support 64Gb.
I assume that EFI runs in protected mode? can real mode be deleted completely? It might mean a new boot loader, but I don't think any current OS uses BIOS calls (except maybe some of the BSDs?) How would the initial GDT be set up? It has been a long time since I've read an x86 architecture manual, and I'm not really a kernel programmer.
The reason railways still use the 4 foot 8.5 inch gauge is because the Romans used that same distance for their chariots. All other vehicles followed the same distance so that their wheels would fit in the ruts of the road and the wheels would not be damaged. That distance continued into the Middle Ages, and when railways came about, they used the same distance between the rails.
So old specs never die!
I think what's missing is that x86 was ditched, over a decade ago. What you are seeing now are varying ISAs (AMD at one time called this RISC86 [do they still use this term? Is RISC86 still used, or was it dumped after the K6?], unaware what Intel calls its solution) on a chip with a small front-end that to the outside world looks like x86.
Slashdot: Playing Favorites Since 1997
That was an early version of NT and they dumped it as soon as they could. IIRC the code was portable because the government didn't want hardware lock-in to Intel (and Alphas were the New Thing). When Alphas didn't go anywhere (Compaq Bastards) they dropped it completely.
Linux still supports ~20 architectures.
I won't mod you down for your opinion, but are you SURE you aren't a Microsoft stockholder or anything?
I played with Vista since the beta releases, and while it looks pretty - I still prefer XP on my machines. It DOES offer quite a few new features, but many aren't ones I feel a huge need for. EG. It has a nice feature to automatically back up the computer. Ok, but it only works for that specific PC. Microsoft's new "Home Server" product coming out 2nd. half of 2007 will automatically back up ALL the PCs on a LAN - which sounds FAR more useful to me. In the meantime, I just selectively back up my important *documents* to CDR or DVDR, and don't worry about the rest. By the time I suffer from a major drive crash and have to restore everything, I'm usually better off using it as an opportunity to start with a fresh new OS install (no registry clutter, etc.) and just restore the needed data afterwards.
The new toolbar features make my desktop feel a little "cluttered" too. I prefer OS X's dashboard, where they're only on-screen when you bring them forward temporarily, right on top of everything else.
When you couple all of that with the "early adopter" pains Vista brings people (poor support for many games, some driver support still lacking for devices, etc.) - it doesn't seem like it makes sense to use it yet.
To be fair, this comes up with EVERY new OS release from Microsoft. I remember a BUNCH of people saying they saw little or no reason to move from Windows 2000 to XP - because XP was "just a bunch of eye candy, including that ugly new Teletubbies wallpaper background". But soon, people changed their mind to a stance of "XP runs faster than 2000 on my same hardware!", and embraced the improved wi-fi support and much more.
What MS needs to do is, on vista install, give users a choice of a theme, the normal vista one, or the XP one. Letting them start with the XP one will give them time to get used to the new features while in a familiar interface. Then when they're ready, they can make the theme switch to the default.
Sure, you can throw them in the deep end and hope they swim, but given the odds that they might drown and become an anti-MS advocate for the rest of their lives is a big gamble, when you can just ease them in right from the start.
I'm not say there isn't transition help out there, tutorials (online, built-in), books, but average users don't want to go through all that (even though they should).
-Tony
Is it only me or anyone else feels a bit unease about lost opportunity with a good cleanup when we moved to x64 ABI (yes, I don't like "x86_64")?
o ns
I mean:
http://en.wikipedia.org/wiki/X86_calling_conventi
Why require 16-byte alignment? Oh, so that xmm data can be stored aligned on stack. But how often do you need it? 0.01% of all stack frames or less? Wouldn't it make more sense to do this alignment when entering functions that needs it (3 assembler commands, right?). Why so many registers allocated for args? Why not drop 387 stack support at all - wouldn't that improve context switching times? (Hmm, I may be wrong here)... Finally why MS felt obligated to come with their fucking own version of ABI?! (Ok, that last one is rhetoric)...
But that's peanuts compared to the whole memory-model / "int" size thing. I mean - do people never learn? At least 16-bit Unicode problems should've tought us something about bean-picking. So now we have cache-spoiling-if-nothing-else 32-bits selecting prefix on every other fucking CPU instruction and you cannot have more than 4 Gigs of executable code, what's that? "640k should be enough for everyone" once again? What if I want some code generator for turning my data into self-processing code? (Old-schoolers may remember "compiled sprites" to get my idea).
x64 is a great step forward for x86 and it could be better if wiser (IMHO) decisions were made in its infancy. Maybe it's too late now but I guess it will bite our asses in the years to come.
oh please, 1GB main ram and 128MB video ram is not old!
Have you seen an office depot/best buy/circuit city flyer lately? They're the computers for 'most' people going-to-buy one. And that hardware is 'new' for 'most' people currently with computers.
Sorry, I really don't know how you define 'most people'. Maybe you mean most geeks. or most hardcore gamers. But i'm a big geek and i only have 512 of main ram and 8 of video ram.
-Tony
HOOAH?
Linux (BSD etc) and its applications run on Intel, ARM, Sparc, PowerPC, IBM Mainframe, and more. GCC produces code for these targets, and more.
The OS and its applications are found in routers, media extenders, video chipsets, and only sometimes use the Intel ISA. Large applications are regularly moved from one platform to another.
We have millions of lines of portable code.
It IS feasible, but it isn't done. The reasons are elsewhere.
Just another "Cubible(sic) Joe" 2 17 3061
I drive a '96 cavalier; Its not stylish, its not particulalry fast, no power windows or locks and due to some dings, its not even orthogonal anymore. But it was cheap, relatively fuel-efficient, reliable and it gets me from A to B as fast as I'm otherwise allowed. We geeks tend to pine over these sleek ISAs like MIPS or Power in much the same way that car enthusiasts wax romantic about the latest sports car. For most of us however, practicality forces us to drive more modest vehicles. Its not practical to drive a vehicle that requires some exotic fuel in the same way that its not practical to run a CPU that digests some exotic instruction set, and for the same reasons: Limited use and availability leads to higher cost-of-ownership overall. Economies of scale and past investment lead to comparatively rock-bottom prices. The PC is also bogged by something far more sinister than the x86 instruction set, namely, the PC BIOS. This is only just beginning to go away with Apple having adopted Intel's EFI firmware (OpenBIOS on their PPC systems before that) and the growing list of LinuxBIOS supported motherboards (still not ready for personal use, but getting there). Widespread EFI adoption might take place if Microsoft releases a home OS with the capability of using EFI without the BIOS compatability layer. Another point to watch for in the future is the proliferation of platforms such as the CLR (.NET) and to a lesser extent, the JVM. These sort of platforms serve as an abstraction layer between the instruction set the software is written in, and the instruction set of the hardware on which it runs. With a performance difference of 10% or so now, and that difference shrinking as the technology matures, we'll begin to see that the underlying architecture will loose its hold on being the defining element of the platform. We're already beginning to see x86 technolgy moving towards extensions to make virtualization (such as Xen) more efficient, and I suspect it will not be long before it moves to include features to make the .net platform and similar technologies run more efficently as well. If these sort of technologies eventually become the defacto target for software, we may see a future in which the CPU's sole purpose becomes to efficiently support a higher-level platform that is defined by software.
In the Embedded world, x86 does not reign - in fact, x86 is a very small portion of the embedded market. PowerPC rules, followed by ARM and 68k, this doesn't even mention smaller processing tasks run by Microcontrollers like the 8051 or PIC devices. x86 has all but been ousted where engineers are freed from the concerns of backwards compatibility and high performance is not required.
HOOAH?
Got nothing except the subject...
When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
the x86 instruction set has been implemented on RISC processors for almost 15 years now. The other processor builders were right in building smaller, cheaper, more efficient RISC's (Power for example) too bad they have always been undercut by the mainstream.
Custom electronics and digital signage for your business: www.evcircuits.com
Is that nobody seems to be able to beat it by any significant margin. When you look at the market in which it is designed for (that being normal laptops/desktops/servers, not embedded devices, high end computation and such) there isn't something that is just hugely better. We saw that with Apple and PPC. Always there was talk of how much faster it was supposed to be that didn't pan out in actual testing, and now Apple has settled on x86.
I mean think how many times on tech sites you've seen a story on The Next Big Thing(tm) that will just spank x86. Does it ever pan out? I'm not talking about being faster on one particular benchmark, I'm talking about noticeably better performance across the board. That's the kind of thing it would take to make a switch worthwhile. I am not going to hop on a new platform because of promises and hot air. You want to convince me to switch, you need to show real improvements on real software.
What it comes down to is that the ISA isn't the be-all, end-all some zealots may make it out to be. Chip design is rather abstracted from the ISA these days and Intel and AMD happen to be very, very good at making fast chips. You have to beat that first before you can hope to get someone to switch. You start showing a 50% or greater performance increase across the board for a similar price, you'll see people start to take notice (after all, some OSes like Linux can fairly easily switch to a new platform).
However at this point nothing seems to be able to do that. Latest hype is about the Cell and who knows, maybe the Sony hype is really true but I am extremely doubtful. Seems more like it is just more of the same. It is really good at some things, like stream processing, but in general use isn't a new killer architecture.
The ia32 / x86 dates back further than the 8086/8088. These processors were built
on top of the 8080/8085, and will actually RUN 8080/8085 code that has been re-assembled
for the 8086 (with a little help of a translator). The register set of the 8086 is
backward compatible with the 8080 and so is the instruction set. That is for every
8080 instruction there is an similar 8086 instruction or sequence of instructions that can
be directly substituted.
Even the 8080 was built on top of an older structure. The 8080 is backward compatible with
the older 8008 cpu and will run 8008 code that has been re-assembled. In this case the
instruction set is IDENTICAL, only the machine op-codes have been changed. More registers
were added, and the address space expanded, but otherwise the two chips are brothers.
So... you can actually take an 8008 assembly language progaram and re-build it to run on
the Pentium4 as the 8008 is a subset of the P4!
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
[ You have clicked to open a program, do you want to open it? ( Allow ) ( Cancel )]
*allow*
[ You are connecting to a web site. They may have malicious content which could harm your PC. Are you sure? ( Allow ) ( Cancel )]
*allow*
You're so right! I mean, it contains all kinds of shiny new graphics that cost me maybe 10% of the system's performance on the brand new built-for-Vista machine. But it's worth it to have totally innovative new features like this dock, something no other OS has seen before! Also, it has state-of-the-art security!
[ Windows Update has just downloaded Windows DRM v8 and the patch for the ANI vulnerability, whereby crappy-looking cursors can 0wn your machine. While this vulnerability is rated as non-critical on Vista, it can still be used to hijack IE. These patches may disable some parts of your computer at Microsoft's sole discretion. We keep logs of anyone refusing to install them. You can refuse, but bad things might happen. Just click the damn okay button. ( OK ) ( Report me to the BSA )]
*ok*
Anyone who'd go back to XP or to a free software platform for trivial things like, say, their TV tuner cards working properly with non-degraded video and sound is just crazy! Who cares if it's a brand new machine, we don't mind spending hours talking to Bangalore, reinstalling drivers that still don't work, or waiting until never for a call-back! We'll never downgrade!
Not that they'll let you downgrade, anyhow. Besides, the EULA probably forbids doing so. Microsoft EULAs like to forbid all kinds of crazy things, I mean, just ask Clippy...
[ Warning! Using MS Agent to publish content disparaging to Microsoft is forbidden by the MS Agent EULA! We reserve the right to have the BSA audit you for license compliance. ( Bend over )]
*oops*
Your arguments are total BS dude. You shouldn't pass that junk off as the truth. RISC was superscalar well before x86 was, since the Crays in the 1960s. Out-of-order execution was realized by IBM research -- look up Tomosulo's algorithm. Pretending that x86 superscalar is less complex than RISC superscalar is just plain silly. Indeed, modern x86 emulates a RISC ISA by decoding standard x86 instructions into micro-ops. Let me repeat that. The superscalar pipeline in an x86 machine is actually executing RISC-style instructions. Furthermore, the Pentium architectures are generally not advanced superscalars. Contrast how pentiums handle branch mispredictions -- by waiting until the mispredicted branch is to be retired -- against more advanced architectures such as the MIPS R10k -- where mispredicts are serviced as soon as they are detected, reducing the performance penalty.
Lets look at the argument of x86 instructions being more compact than RISC instructions. They sure are more compact -- in the binary stored on the hard disk. When modern x86's pull these instructions in, they get decoded into micro-ops which are then stored into a trace cache. That's right, the instruction cache that Intel hopes is being used to read instructions stores RISC instructions because it is far more efficient for execution. Also, since instructions are stored in traces, a single micro-op can appear many times within the trace cache -- it just leads to higher performance to fetch work this way. So again, no, RISC instructions don't screw up the instruction cache. The modern x86 instruction cache actually stores RISC-style instructions.
The reason that x86 outperforms other architectures is largely due to the MHz scaling they were able to pull off. By playing in the large commodity CPU market, as opposed to niche supercomputer processor markets, they earned a ton of money. They wisely invested this money back into their chip FABs. Intel VLSI and manufacturing prowess is what led the big crush against the supercomputer processors. Intel microarchitecture actually emulates RISC microarchitecture -- their marketing just requests they don't broadcast that fact too loudly.
Before Intel's marketing guys got hold of it, the byte order in a mainframe or a Motorola CPU was known as "normal", as the bytes are in the order people usually think of them - Most Significant first. The Intel one was known as "Byte Swapped".
I can never remember which end of my egg I should eat first, so avoid Intel's terms.
In their favour, I think byteswapped actually works better - it's just not what most people do.
- Drop support for 16-bit mode and all the old instruction forms designed for it.
- Remove some of the esoteric instructions that were rarely used even 25 years ago, like DAA and AAA. This is a trivial savings, of course.
- Only support SSE for floating point and not the old floating point stack.
- Remove MMX, which never caught on anyway.
All of these have backward compatibility issues. Apple had an interesting opportunity to disallow the above features when they switched to x86 chips, opening the door for Intel to finally remove some baggage, but that would have killed Windows compatibility.How can one talk about simplifying the x86 architecture without noting that Intel actually tried it? The Intel 80376 was a variation of the 386 that removed support for real mode.
We don't have inductively coupled connectors because they are lossy, expensive, and drain power even when not in use.
Contribute to civilization: ari.aynrand.org/donate
Apple switched Mac to x86.
Linux is available for x86.
The clearance system sounds logical. It is not. It is completely arbitrary. -- John Bolton
One way to phase X86 out gracefully is to put 2 chips in machines: one X86 and one that is the new standard. X86 apps run on the old chip and non-X86 apps run the new one (or an emulator if one or the other is not available.) The new standard chips should be fairly cheap because they would not have to contain a lot of backward compatibility baggage.
Table-ized A.I.
about technology that was developed when Jimmy Carter was in the White House and the soundtrack for the John Travolta movie Saturday Night Fever was the best-selling album in the United States.
Hell, that's reason enough to phase it out.
Table-ized A.I.
"It was originally thought about as an eight-bit chip ... designed to run spreadsheets," said Phil Hester
Earlier it said the chip was released in 1978. Spreadsheets were invented in late 1978 or 1979 if I remember correctly, and it was not until 1980 that spreadsheets caught on big. If the chip was released in 1978, then it was probably designed around 1976 and 77, well before spreadsheets were anything to anybody. Microcomputers ran BASIC in 1977, and that is just about it as far as commercial/standard software. Maybe they are talking about the 8088 instead of 8086, but it seems otherwise.
Table-ized A.I.
Imagine that there is a "bogomips limit", where the machine works well enough to run Windows 2000 + IE, or linux + KDE. As soon as somebody makes such a chip (chinese manufacturer), all they have to do is:
...).
1) patch gcc to generate code for it (6 month project)
2) patch oss kernel (linux) to work.
Theoretically, then you can run all OSS software, including qemu for windows.
The only problem is that software vendors push forward the "bogomips limit". This was a standard practice of Microsoft where each new version of windows required a hardware upgrade. But the last years linux distributions are even worse (Mozilla, OOorg, AJAX,
If the bogomips limit was fixed, x86 would be phased out.
give MS more reason to foist WGA on those of us that actually pay for it. Yeah, fucking brilliant idea there. It's bad enough that most 'computer consultants' don't know how to do simple shit like make the system work with what they have, no we'll just pirate it and downgrade. Genius.
What are you going to do when the guy calls with a WGA notice? You'll look like an ass and give the rest of us who do things the proper way a bad rep.
It's not your job to decide if the customer needs a legal copy or not. It's your job to provide the proper licensed software, and the service of setting the machine up. This would also be the time to offer alternatives like Ubuntu or Knoppix and let the customer test the waters, you might just get another convert this way.
...unless there is some unseen object that the Nazis posses I think you mean "possess" unless you are talking about groups of Nazises that roam around and cause problems in modern urban areas or the Wild West.The store string instruction was not particularly efficient (fast) in the early implementations, and the setup often made it less than useful.
But there's another reason your instructor was mad at you. Yes, the mechanically generated instructions could have been replaced with more efficient sequences. But you do _not_ want to do that in your first pass with a mechanical translator, especially if it's the first one you've ever written. Once you know what you're doing you can build optimizing passes and combine passes and such, but if you knew that much there would be no reason to take the class you were taking (unless it was just for the grade) and you should also know better than to try to confuse the other students.
joudanzuki
"But, look at x86 and its dominance over itanium. Itanium is a *good* design, but x86 is outcompeting the hell out of it because with a kludge here and a workaround there, it could be iteratively fixed up to outperform itanium."
I think you're missing the point though, EVERYTHING has attributes that change depending on displacement costs that are directly linked with the goals of the design you make. Any design you come up with that is by necessity *static* (fixed, unchanging) will never hit a moving target (new requirements = goals that have changed).
And if you're going to talk about how life is badly designed, life is far, far more advanced then our technology. Computers do not understand anything we have not told them to understand, they need our backward little biological minds to tell them what things mean and how to do things. While we might invent technology that can do things we cannot do innately, the thing people forget is... all of our technology is an extension of millions of human brains that have existed, that is one hell of a technological bed. While some people might say mankind is weak or whatever, again: They ignore the laws of nature, can you grow a living being from an egg the size of a the head of a pin?
People love to mock biology without understanding its underlying technological complexity, most people here do not even understand evolution. The fact is Darwin's only competition was a biblical mythology, hardly biological evolution FTW... and biologists still have not solved Haldane's dilemma, a huge mathematical roadblock if one is to understand the how if the how doesn't work logically mathematically, like the real world(tm).
I don't think you understood that. But, I would hope register renaming would catch that sequence. Can segment registers be renamed?
And there are processors that can do you you were thinking about without any of those steps. Not all processors are equal.
why 10x the power of the fastest X86? Because no one is going to 'junk' their existing and working software. And the new CPU has to run the existing X86 software at what seems to be the most acceptable emulation speed for PC users. The software community generally accepts that it takes 10 times the processing power of the emulated CPU to appear to be the emulated CPU running at full speed.
And at less than 10 times the power of the current X86, developers are not going to invest the large amount of money and retraining needed to develop next generation software on a completely new platform.
I come from the embedded systems world. Getting a 10 times more powerful CPU for about the same price as the CPU that you are currently developing for is not uncommon and happens every ten years. It is happening now as all the 8051 programmers; all the PIC programmers; and all the AVR programmers are beginning to realize (one by one) that there is a standardized 32-bit ARM processor that is reaching the $5 US price in small quantities.
It's not easy to switch devices; but we seem to do it every ten years or so. I learned on the 6502 in the Commodore 64 and the Motorola 6800 family on the Radio Shack home computers. Then I learned and used the Intel 8051 for ten years. Having gotten tired of wire-wrapping and 100+ connection PCB layouts, I switched to the Atmel AVR about ten years ago. Now, with not a little dread and excitement, I approach the ARM.
The 'rule' that any new processor has to be about ten times more powerful for the same price as the current 'general-use' processor seems to hold well in the embedded-systems field. I suspect that it applies to the general CPUs used in office and home PCs as well.
for many applications (especially now that characters are not 8 bit), for people who knew the instruction set.
Theoretically, anyway. Too many of the optimization architects for the m68k compilers didn't seem to understand the instruction set, however, and Motorola wasted a lot of time playing with complicated addressing modes in silicon when they should have some college intern first analyze the effect by substituting proposed op codes into real code.
I have often thought that Motorola would have benefitted greatly if they had simply written more sample code for their CPUs. iNTEL's lead in the visible sector (as opposed to the sector of the market most people overlook, where they have no lead at all) was primarily fueled by a corporate attitude that fostered sample code and cheap sample hardware, and we still see them with a somewhat better relationship with the free software and open source software communities than Freescale and many of their other competitors.
(And it's the lack of cheap sample hardware that is slowing PPC and ARM in the desktop sector. It appears to me that the difficulty of getting cheap dev/test boxes is directly related to the popularity of the chip in the embedded sector. And it still bugs me that I can't re-program my wristwatch.)
m6809 was even more efficient, although the couldof's and the wouldof's make it impossible to discuss meaningfully any more.
(And if you want to look at efficient ISAs, look at the descendants of the 6805. EEEEUuuUUGGGHHH!)
joudanzuki
The real problem with itanium is that you simply can't optimize the entire program at compile time.
If you could, you would only need one instruction, but that would not be a very exciting world for computer scientists.
(NOOP, if you have to ask.)
embedded base.
Except that, until we get the GPL ironed out, whatever is in embedded stuff isn't re-programmable, so it doesn't alter the momentum of the re-programmable sector.
are the culprits, I think
mod parent up. this is the truth!
was sample code and _cheap_ sample hardware. And it's still the same.
I know that, when you have embedded applications eating up all the output of your fab lines, it sees extra expensive to feed the guys who are eating dirt and going naked to build something in the garage, but some of those guys eating dirt and going naked today are building the killer applications that make the new markets tomorrow.
Besides, a CPU vendor that doesn't write (lots of) code for their own processors really won't have a grasp on the effects of various aspects of their own processors' designs.
And, why they dropped the 6809 and built on the 6801, I don't really want to know. But it was possibly their worst strategical error. (Spiting Hitachi? Competition with their own 68k?)
that IBM built based on the M68K, and, yes, it cost about twice as much, as I recall.
http://www.old-computers.com/museum/computer.asp?s t=1&c=623
because it requires a fundamental change in the basic run time to justify the extra OS stuff to support it.
And everyone is scared of change.
Explain yourself.
Now, what y'all wanna do?
Wanna be hackers? Code crackers? Slackers
Wastin' time with all the chatroom yakers?
9 to 5, chillin' at Hewlett Packard?
https://www.eff.org/https-everywhere
This is something I find most embarrassing concerning x86. Besides the clock speed increase, have we seen a 1000-fold performance increase with that increase in complexity? Sure, some of that complexity has bought about performance increases, we've gone from 8 to 64 bit, and we've got SIMD now. Still, there's a four-fold increase in complexity that isn't accounted for there. I'd rather see all those transistors do something useful, and with the advent of FOSS operating systems, there's some chance one of the big chip makers to turn that four-fold increase in transistors available into useful performance.
We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
waiting to happen.
Or an off-by-one. Or one of several similar coding errors that lead to vulnerabilities.
And, since packed structures tend to change, and then new code on old structures tends to fail silently in least significant first CPUS precesiely when the count crosses the byte boundary, this kind of programming tends to corrupt data.
But you were aware of those, and assuming that real programmers never do such things?
By the time you take care of the corner cases, byte order advantages disappear. Better to just load and store what's there.
And, as far as trying to get a word or long word out of a byte string, why would you want to do that? What happens when you want three bytes, or five? Do you really want to let the CPU stall when you grab misaligned data? How much do you really gain by not having the patience to move the byte string one byte at at time?
You do understand that the block move optimization that checks the length of the block and shifts gears to register-wide moves for blocks that are long enough to justify the shift work just the same in any byte order?
I'm going to let your comment on VAX slide, because I don't remember whether or not the NUXI business was PDP or VAX or both, I don't have my source code from college that would tell me, and looking it up on the web reveals a lot of people building web pages on byte ordering who don't seem to understand teh NUXI problem at all.
joudanzuki
And then you talk of descriptors and macros.
I sense some confusion.
But concerning buffer overflows, descriptors only help if you don't have control over the interpretation thereof. And unless those descriptors handle general arrays, you've still got buffer overflows. Unless, of course, the macro generates instructions to grab an address as a parameter and reach out into allocated memory, etc., in which case you are now talking about BASIC or C# levels of abstraction. And by that time, you don't care about bytes and words and byte order at all.
Most significant byte first, least first, either the variable is allocated assuming long word access, or it has to be moved when the variable size changes. The indirection of descriptors can't change that fact, either.
I will grant that with least significant first, iff you pre-allocate the thing to the register width and clear the whole thing first, and simply access it as a byte if you think it's a byte, the bit pattern doesn't vary when you access it as a word. But where's the advantage?
And you still have at least the problem of whether your code tries to interpret 0b10000000 as plus or minus 128, and that defintely is a problem when you don't know whether you're grabbing a byte or something larger in least significant first.
The problem I have with least significant first is pretty much derived from the (apparent) convenience you claim. My experience is that it tends to induce silent, data corrupting errors. A good compiler can pretty much cover those cases silently, but, as I say, whether the compiler or the programmer covers the boundary and corner cases, they have to be covered to have dependable code, and then you lose any real effect of the supposed convenience.
And your ordinary C compiler doesn't cover the corners and edges, and that's part of the reason Microsoft's code tends to be full of holes.
On the gforth mailing list just now, I saw some exchange from someone moving some code from pygmy forth to forth. Apparently, in pygmy forth, the entire heap, allocated or not, can be accessed without generating bus errors, so someone implemented a little random number routine that took the random number from the library routine and used it as an address. It seems to work.
I think it's the same with this particularly "advantage" of least significant byte first. It tends to foster programs that "seem" to work.
The one argument for least significant first that I will acknowledge (though I don't at this time agree that it makes it prefereable over most significant first in CPUs) is that it keeps the digit number and the power of the base the same. It is sort of aesthetically pleasing. Oh, and there's that metaphysical business of emphasizing the one over the many when reading from low addresses to high, which is the usual procession.
joudanzuki