Slashdot Mirror
Linus: Praying for Hammer to Win
An anonymous reader writes "The boys at Intel can't be happy with the latest opposition to the IA-64 instruction set. According to this Inquirer scoop, Linus himself has weighed in, and it appears he's putting his eggs in the x86-64 basket. In the original usenet post, he goes so far as to say that 'We're ... praying that AMD's x86-64 succeeds in the market, forcing Intel to make Yamhill their standard platform.'"
Considering that Linus is almost fanatical about needing to "break" backwards compatibility in the Linux kernel in order to develop it as fast as possible.
Now he's supporting a CPU scheme that, well, doesn't break anything and may even sacrifice performance for that compatibility.
Moderation: Put your hand inside the puppet head!
I thought we supported this stuff for the other 64 bit processors? Aren't we fully 64-bit yet?
Stop the brainwash
Beside that, who cares for the CPU's instruction set? Nobody, except compiler designers and very few assembler programmers.
Umm, you are correct, but you have to keep in mind that Linus Torvalds is in that set of very few people. He may not be the one writing the compiler himself, but he is extremely close to the compiler-- he works on the operating system kernel, the one position that has to be most sensitive to obscure conditions of the microprocessor in order to optimise. Which is why he is weighing in on this subject.
Anyway, most of us have heard of Torvalds' fondness of hand-writable assembly language. (I.e., the huge portions of early Linux that were written in x86 assembly and C code which is written in such a way it may as well be assembly.. I had heard things indicating he had mostly grown out of that lately, though, now that non-x86 platforms are closer to his chunk of the kernel tree.. is that the case?) And i think we are all well aware of Linux's famed nonportability to non-GCC compilers due to dependence on obscure GCC bugs and nonstandard features. So, yeah. Linus may not be The Compiler Guy, but he will definitely have to be talking to the Compiler Guys on a regular basis, and he is in the group of people (the linux kernel development team) most likely to be the first ones to run into trouble with any new bugs which crop up in gcc. So he definitely has a good reason to have an opinion on this subject, especially given the subject increases compiler complexity so much that it is somewhat likely to increase the number of small compiler bugs that make no difference to you or i but huge amounts of difference to those persons who know what "spinlocks" are..
- super ugly ultraman
Don't you see it comming.....all the way down to hardware...on one side the DRM and such products and the other the open systems
Yes, he's praying for standardization, using AMD's standards which is directly related to Hammer's success. Itanium was to be Intel's one and only 64-bit future, and only when faced with AMD's 32-bit backward compatible architecture did they design a fallback, the Yamhill, which would be compatible with the Hammer and legacy apps. The headline is *not* misleading at all, for once, he wants AMD's Hammer standard, not IA64.
It seems odd though. Putting aside market situation and prices to look at the pure technology aspect of it, IA64 is a better architecture, it isn't burdened with backwards compatibility. Especially with linux (which already works with IA-64, as well as most apps), there is little reason to hold on to the dated IA32 architecture, which inherits stuff from early 80s. I could see why MS would be on the x86-64 bandwagon (if users' upgrade paths force them to change architectures, they may be just as likely to go PPC as they would IA64), but not Linux...
It made sense when moving to 32-bit from 16-bit to keep backwards compatiblity, assembler was widely used back then out of necessity, and thus porting applications was non-trivial. Now, in an age where most everything is written in high-level languages, this is the perfect opportunity to start with a clean slate. Companies can easily recompile and do additionaly testing and earn back the money it cost to do so in short order, if their application is important to the market.... Of course all of this is from a technological standpoint....
The fact of the market is that Yamhill/x86-64 is the future of x86. Itanium was a nice dream and all, but when you look at the two platforms and the variety of software they support, the choice is clear. Not everything will be ported to IA64 and knowing that it is hard to justify the jump...
XML is like violence. If it doesn't solve the problem, use more.
OTOH, it makes some sense to keep things the way they are.
Consider that the internal core of a perfect-new RISC chip and a x86-64 chip are more-or-less the same. x86-64 instructions come in, are translated to internal RISC code, and are then executed. The main difference is an extra translator and the register-renamer. But any architecture that lasts long enough will need such trappings, as it starts being used for things that nobody would have thought of when the designer thought the chip up.
Remember that, for a long time, the 286 instructions that aren't easily mappable to the RISC core aren't particularly efficent.
I used to think exactly the same thing as you are thinking now. I want a MIPS or Alpha inside, not Intel. But, given that 99% of programming is not done in assembley and the cost of adding a hardware instruction set translator is minimal compared to the difficulty and risks of switching instruction sets, the instruction set of a processor ceases to matter.
Gentoo Sucks
If AMD is successful in forcing Intel to adopt x86-64, great harm will be inflicted upon:
While recent interviews with HP execs (on The Register) indicate that HP is taking some steps to "roll with the x86-64 punch," I sincerely doubt if HP can be convinced to port VMS to Opteron should it become necessary.
What is even more troubling for the Itanium is the fact that HP's compilers are faster than Intel's, but the HP compilers have not been released outside of HP-UX. The standoffish attitude of other ISVs (Dell, IBM, etc.) is not hard to understand given these circumstances.
You will also have noticed Microsoft's (now infamous) "leaked" memo on Windows-64 running on Opteron. Such a leak I believe has been carefully crafted to throw FUD upon all things Itanium. Furthermore, it is in Microsoft's best interests for Opteron to prevail, as such a victory will destroy not only DEC/Compaq's high end, but also HP (as much as HP-UX deserves to die, it should not fall to Microsoft).
If Intel and HP truly want Itanium to flourish, Intel must reduce the price immediately (to at least a SPEC-to-SPEC match with Athlon/Opteron, and possibly lower), and HP must release fast compilers under an open license.
If the Itanium market remains fragmented, AMD wins, and Microsoft's interests are advanced.
Have you compared the die size of Itanium vs a Xeon or Hammer? Itanium is much larger --- and slower --- and more expensive. Who's wasting die space?
But hey, at least it's pure!
Please port OSX to Hammer and stick AMD chips in your Macs. You can save face by pretending it's not x86 (even though it will make customers happy when they can run WINE and VMWare on OSX). Your programmers will enjoy the relatively clean 64-bit mode. You won't face the risk of being the sole customer of your CPU vendor. Best of all, you will be able to make cheap Macs with competitive performance. I promise to buy one if you do it.
Sincerely,
Robert O'Callahan
> using SSE2 instead of x87 is a decent compromise
In fact, it's significantly faster. Latest gcc has a switch to do this.
BTW, you're ignoring the fact that x86-64 is a significant improvement over x86, not just a 64-bit stretch. 8 new general purpose registers, 8 new SSE2 registers. It starts to look a lot like a real architecture, yet compiling to it is very little different from compiling to x86.