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.'"
it's an internet tabloid creating a mountain ("Linus himself is praying that AMD wins!") from a molehill (half a sentence in an unrelated USENET post).
crap story.
Cretin - a powerful and flexible CD reencoder
It's amazing that somebody could make such a relatively long article from what amounts to one sentence in Linus's email!
Reading the Linus's email it seems that he wasn't endorsing one way or the other. He was just hoping x86-64 became dominant since it would stave off some issues related to how pages were handled.
Apparently, if things go the Itanium route then some page related things get more complicated but that's it.
Nothing to see here. Move along.
--
"I'm too old to use Emacs." -- Rod MacDonald
First, this was not a USENET post. It's a message from the linux kernel mailing list that google is pumping into their groups.google.com database. Second, Linus is not saying he thinks Hammer is a better architecture. What he said in this message was that the current Linux page table implementation is not ideal for use with IA64 and therefore, for the sake of Linux servers everywhere, it would be better for Hammer to provail in the near to medium term future. I don't know his real position, but I would be very surprised if Linus though Hammer was a "better" architecture. X86 is an awkward instruction set that has been perpetuated by software designed to run on it. The core of these chips like Pentiums are really RISC chips with hardware wrappers to implement the X86 instructions. So it's just a waste if die space. IA64 is purer and a much better long term choice. Don't over analize a simple e-mail message from someone on lkml. These are not markedroid approved public service announcements.
it's funny how people ripped and ripped and ripped on Intel all through the 90s about keeping all their backward compatibility from 286 on through the P4. how people said they should cut the dead weight, etc.
well, now AMD is creating the kruftiest, heaviest, nastiest instruction set of backwards-compatible crud in the history of processor-dom. Intel comes out with a new, no-legacy 64-bit instruction set, and all of a sudden it is, "god, we hope AMD wins so all our old crap still works".
well anyway, here's at least one programmer who is looking forward to getting his mitts on a 64-bit chip which doesn't have layer upon layer of backwards compatibility, wrapped in an overpowered muscle-car of silicon. you'd think we would have learned our lesson with the Alpha, a much, much better chip than the x86 but no one adopted it. people scream and bitch and moan about supporting all the ancient krufty x86 bloat, but when it comes time, they stick with what is comfortable.
more than likely, Intel's 64-bit offering will follow the road of Alpha into technical superiority and market disaster. and we'll be stuck still supporting 286 instructions. way to go.
MORTAR COMBAT!
What endorsement is that? AMD has been utterly piggish with respect to open source. GCC still produces awful optimizations when targeting any AMD chip, and in fact has gotten worse between 2.9x and 3.x. Intel started out contributing pgcc when Linux was still in its infancy, and code output for Pentiums has gotten successively better. When bad optimization can halve your effective computation rate, that I think speaks volumes.
That said, I have to agree with Linus on this one. Itanium would be a disaster for free compilers, as heavily encumbered as it is by compiler technology patents. And when it comes down to it, I'm not all that certain I want my general purpose language compiler generating what is effectively microcode anyway.
IMHO of course.
--
BitTorrent in C -- LibBT
http://www.sf.net/projects/libbt
We're a lot more likely to make PAGE_SIZE bigger, and generally praying that AMD's x86-64 succeeds in the market, forcing Intel to make Yamhill their standard platform. At which point we _could_ make things truly 64 bits
He wants hammer to succeed only so Intel will have to go 64 bit and they can go all out 64 bit, this is not Linus picking the AMD camp.
usernet post here
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
I'm not some prodigal kernel developer, but I do think the AMD architecture looks like a piece of shit. You're really telling me that we want to have an architecture that operates in a 16, 32 AND 64 bit mode, that has tons of crufts and kinks from the 80's still in it and a paltry handful of registers that are all overlaid... A(H|L) -> AX -> EAX -> 64-bit AX? Why? what the hell would that be good for? just bloats the die by another order of magnitude I'm sure.
Intel's got a sound solution and they at least have the balls to finally give the cruddy old x86 architecture the heave-ho; ok they can't do it now but IA64's architecture does not require 8086 or IA32 to bootstrap it so both can be thrown out sooner or later. Regardless of what the actual metal might be, the actual platform is beautifully elegant next to x86 and will ultimately be a real asset in the future as 64 bit architectures become the norm, much more so than some short term gain that might be had by virtue of a superior implementation from AMD.
Maybe I'm missing something here (OK I'm not on the design teams for both processors so I certainly AM missing something here) but from this standpoint, it looks like this would be the one time when I want to cheer for Intel as opposed to AMD. Pity they had to botch the development cycle like they did. *sigh*
Even if desktop PC's migrate to 64 bit in the next couple of years, you still have all the other embedded devices out there running on 32bit CPUs. There is no need for these devices to use a 64bit CPU - for these applications 8megs of memory is plenty, 4gigs is just crazy!! This is why 8bit CPUs (and even some 4bit) are still in production today and in much greater quantity then those 32bit CPUs found in desktop computers.
If linux is to be used in such devices, it'll have to support 32bit architectures.
PS, PPC chips are 32bits. IBM Power chips are 64bits but they are actually different from PPC chips. Code written for one doesn't run on the other - something the Mac rumor mongers simply don't understand with their "Apple is going to use a IBM Power CPU" bs.