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.'"

Comments

One endorsement down, one to go

[sgtsanity]

Now if AMD can get the endorsement of "The Carmack", they will really be happy.

Re:One endorsement down, one to go

[CaffeineAddict2001]

Carmack and Linus look very similar. I think they are actually the same person living a double life. He may fool you with that phoney norwegian accent, but I know the truth.

what a trashy article

[krog]

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.

Re:what a trashy article

[tcc]

Well I guess it depends on which point of view you are looking at it.

Carmack posts something here, you get instant linkage and stories out on most gaming sites pointing to that post.

Gates says something, everybody jumps on his speech and tries to analyse everything up to the point of what he had for breakfast, and his intentions for the next 20 years.

Jobs farts, mac users are all exited, etc etc..

The idea here is some people follow this stuff religiously, while for you it might be pointless for some others they really dig that stuff. Tabloid are way more crappy and unreliable than this story, and the worst? They sell like hotcakes.

To give you an example, I've found slashdot by a linkage of an amiga story. While I am not a Linux freak or "your rights online" active militant, I do have my own "tabloid" stories that I like to follow (like amiga stuff for example).

I've had the same reaction when I saw the article ("my, talk about far-fetched") but when you go and read the usenet post, it can make you think. If you don't care about linux and/or processors/os, well, you skip the story and move to the next, if you do like the hardware/OS scene, it makes a nice read, to get back to my idea, it tells you that if Linus wants the x86-64 to win, maybe they are designing the transmetta's next gen on that instruction set?, maybe this maybe that. Nevertheless, for people who like that kind of stories, it's a bit above the tabloid I'd say, because it's not a quote out of context and it's authentic.

my 0.02c.

Not surprising...

[tjansen]

Not surprising... he works for Transmeta, and they licensed x86-64... So what else should he say?
Beside that, who cares for the CPU's instruction set? Nobody, except compiler designers and very few assembler programmers. And they already know x86 and the tools exist. So the only argument for Itanium can be performance/price. And ATM it looks like Opterons will be cheaper.

Re:Not surprising...

[Anonymous Coward]

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

Re:Not surprising...

[Courageous]

Beside that, who cares for the CPU's instruction set?

A bit ironic, that remark. That's basically what the AMD guys decided when they went for X86-64: that the instruction set really didn't matter, and that it was implementation and good ole' Moore's Law that really counted. Meanwhile, when the instruction set doesn't matter, you've got Intel spending a cool $10 bill on theirs. So, I have to say, I find your remark quite amusing.

C//

Just wishing...

[Chexum]

I see only Linus daydreaming about keeping x86 (the well-known and optimized standard bytecode at Transmeta, remember?), so that the 64 bit extensions get more widespread, thus "rest of us" can afford to get 64 bit architectures on this very same architecture we grown up with... On the other hand, it's a good goal :)

Re:Just wishing...

[gmack]

I think hes dreaming about 64 bit for the masses.
As would anyone else who has had to get 32 bit x86 to handle more than 4 gig of ram or tried and figgure out how to juggle the few registers provicded as efficiantly as possible.

I for one am also wishing for cheap 64 bit.

This is a bit ironic..

[Marx_Mrvelous]

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.

Re:This is a bit ironic..

[gmack]

That is _only_ true for module interfaces. In the past hes been very picky about changes that break userspace.

Re:This is a bit ironic..

[Dominic_Mazzoni]

Now he's supporting a CPU scheme that, well, doesn't break anything and may even sacrifice performance for that compatibility.

Except that it's quite likely that an Opteron will be faster than an Itanium for most real-world tasks. At the very least it looks like it will be comparable in speed, and cheaper. If the Itanium really was screamingly fast, that would be different.

"Praying?" Hello? First Amendment?

[Anonymous Coward]

You might want to change the title of this story to "Hoping for Hammer to Win." Who's praying? Ever heard of the separation of church and state? Jesus.

Atheists are the last group of people who are still acceptable to oppress.

Re:The problem with Hammer.

[GigsVT]

Yeah, that whole 16 bit to 32 bit transistion never happened either. People just didn't want to update their code.

Mountain out of a molehill

[Zooks!]

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.

Linus's Prayer

[markatwork]

Now I lay me down to sleep.... I pray Intel the IA-64 Instruction set to keep. But if Intel folds before I wake, I pray AMD picks up their stake (of the market).

(OK so the last part sucks, but still ....)

Re:Linus's Prayer

[Creepy]

What?!?

Sure you can! Which commandment does that break? Thou shalt not mock scripture? Haven't heard that one... must have been one on the tablet Moses dropped. I give you these 15... smash... 10... Ten Commandments!

Ok, it was funny until some holier-than-thou Anonymous Coward busted a couple of rounds in my ass. Psychotic fundamentalists...

good thing Cowards don't get mod points ;)

Re:Linus's Prayer

[Flower]

I prefer this prayer.

THIS IS MY KERNEL. There are many like it but this one is mine. My kernel is my best friend. It is my life. I must master it as I master my life.

My kernel, without me is useless. Without my kernel, I am useless. I must compile my kernel true. I must debug faster than the proprietary who is trying to FUD me. I must outperform him before he outperforms me. I will...

My kernel and myself know that what counts in this war is not the bogomips we reach, the cpus we scale, nor the filesize we achieve. We know it is the core dumps that count.

We won't dump.

My kernel is human, even as I, because it is my life. Thus I will learn it as a brother. I will learn its weakness, its strength, its modules, its vm, its #defines and its compile time. I will ever guard it against the ravages of binary modules and IP claims. I will keep my kernel efficient and ready, even as I am efficient and ready. We will become part of each other. We will...

Before God I swear this creed. My kernel and myself are the defenders of my PC. We are the masters of the proprietary. We are the saviours of my life.

So be it, until there is no proprietary, but Free!

Ok, ok, I admit it needs tweaking.

no AMD vs. Intel

[reverse flow reactor]

Maybe I misinterpreted the original post, but I thought that this had more to do 64-bit vs. 32-bit (and the limitations of a 32-bit platform) than it has to do with AMD vs. Intel.

The kernel compiles on so many different architectures, but with most of them being 64-bit (PPC, sparc, MIPS...). However, i386 is the dominant architecture by sheer numbers. To maintain crosss-architecture compatibility, the code has to support the lowest quality architeture (i386). By pushing towards a 64-bit architecture, the limitations of 32-bit can be left behind (oh yeah, but the nasty issue of backwards compatibility).

Unless I just misinterpreted the post.

So what's next Coke of Pepsi?

[Wizri]

Hey Linus,

What should I drink?

Thank alot,

Wizri,

Clarification

[KidSock]

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.

Re:Clarification

[roca]

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!

Re:Clarification

[Waffle Iron]

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.

Except that two CPU generations from now, Intel will have had to change the underlying architecture of the IA-64 chips to get performance improvemets, but they'll have to leave the instruction set compatible. So, they'll have a hardware wrapper around the IA-64 instruction set. And this wrapper is going to have to try and second-guess the output of those rocket-science IA-64 compilers and rewrite the results on the fly.

Why not just leave well enough alone and let the CPU rewrite code from today's simple, well understood compilers? The current x86 instruction set works like a bytecode VM. There's nothing wrong with that, especially since the IA-64 CPUs and compilers haven't exactly been blowing away the x86 chips in the performance area.

Re:Clarification

[Ralph Wiggam]

The parent poster went out of his way to say that IA64 was his choice in the "long term" and didn't mention Itanium once. He was talking about instruction set design, and you rebut with specific CPU implementation. Yes, Itanium is a giant monster of a CPU that will probably fail on most levels. But don't judge an instruction set based on the first implementation out of the gate. They'll get a lot better at it in the near future. The Pentium Pro was a big disaster (not a new instruction set, but new core). The engineers learned from that experience and came back with some damn fine chips.

-B

AMD's kernel summit presentation

[awptic]

For anyone who has an hour and a half to spare... AMD (along with a few people from SuSE) made a great presentation on the X86-64 technology at the Linux kernel summit in Ottawa a little while back; the MP3 and OGG files are available at the sourceforge kernel foundry.

Why is this so groundbreaking?

[Jeppe Salvesen]

I thought we supported this stuff for the other 64 bit processors? Aren't we fully 64-bit yet?

x86, why can't you just die?

[MORTAR_COMBAT!]

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.

Re:x86, why can't you just die?

[cmowire]

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.

Re:Momentum

[Anonymous Canard]

To me this is an impressive endorsement. Given the overall support that AMD has given Linux over the years, it is great to see a little bit of that given back.

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.

Re:This is FUD

[JPriest]

This is _exactly_ what Linus said

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

Re:Makes sense to me....

[binaryDigit]

but really, what advantage does it have on the high end not offered by Power, Sparc, PA-Risc, etc

Simple, the ability to run M$ operating systems (which the other chips no longer have). As long as M$ has it's weight behind the thing, then Intel will always have a significant advantage. Reasonable (though not stellar by any stretch) x86 compatibility also helps.

Market Split comming!

[3seas]

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

And what Sir Linus says is gospel truth is it?

[Second_Derivative]

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*

Re:And what Sir Linus says is gospel truth is it?

[barawn]

You're right - from a theoretical standpoint. And, if all things were equal, IA64 should utterly rout x86-64.

However, things aren't that equal. First off, x86 has had a lot of work thrown into it, and the current processors are quite good at implementing x86: I doubt there's a huge architectural penalty anymore - you can build virtually identical PPC and x86 computers and compare them, and even though PPC is a much better architecture, it's not going to blow x86 out of the water. Yes, it's idiotic to have, for instance, a stack-based floating point implementation, but the P3 and Athlon both make FXCH free, so it's not that bad anyway, and the P4's SSE2 implementation isn't bad, so using SSE2 instead of x87 is a decent compromise.

Ars Technica (www.arstechnica.com) actually has a good writeup of why we should stop treating x86 as this bastard dog of an instruction set, although they mostly relied on the fact that we have a huge installbase of x86 software.

Honestly, I doubt x86 decoding seriously bloats the die that much - jeez, on a 0.13u process, how big would the original 8086 core be? Take a look at the die for a Hammer processor - x86 decoding doesn't take that much space.

Just wait and see, that's my answer. Let the benchmarks prove AMD or Intel wrong. Intel's really relying on the brilliance of compiler writers, whereas AMD's banking on tons of experience. We'll see who has a better strategy...

Re:And what Sir Linus says is gospel truth is it?

[roca]

> I do think the AMD architecture looks like a
> piece of shit.

You obviously don't know anything about it. In 64-bit mode Hammer gives you 16 general purpose registers (RAX, ..., RDI, R8, ..., R15) and 16 floating point registers (you are encouraged to do all FP using SSE2 and forget about the x87 crap). The GP registers are not overlaid (e.g., the 8-bit instructions access the bottom 8 bits of each register; AH,BH,CH,DH are not available). 64-bit mode is cleaner than x86 in other ways too.

> the actual platform is beautifully elegant

Unfortunately you can't run programs on the "actual platform". You can only run programs on the slow and expensive Itanium and Itanium 2.

Re:And what Sir Linus says is gospel truth is it?

[roca]

> 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.

Re:Misleading Headline...

[Junta]

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...

completely misunderstood: out of context

[jpc]

If anyone actually read the lkml context, the remark was entirely in relation to the flood of recent patches making everything on 32 bit platforms support 64 bit sizes. Once upon a time it was just files over 2GB, then it was block devices over 2TB, now it is all sorts of shit because vendors are selling 32 bit machines that support 64GB of RAM.

Now Intel of course just reckons that people should buy Itaniums if they want this (and apparently they did actually ship 250 of the Itanium 1...) but someone is buying these. Even though you have to use 32 processes in order to use the memory.

Clearly these machines should be 64 bit, thats what Linus was commenting on. Then we could leave at least some of the limits for 32 bit machines without complaints.

The other problem is non-atomic 64 bit ops on 32 bit machines, incrementing counters and such. This has caused quite a few problems recently.

Linus: Size Pressure on "struct page" due to HIMEM

[coupland]

In shocking testimony uncovered by The Inquirer, Linus Torvalds has publicly stated that the size pressure on "struct page" is largely due to HIGHMEM! This ground-breaking statement was a crushing blow for HIGHMEM fans, but received applause from struct page supporters. More information on this ground-breaking revelation as it unfolds...

:P

Let's look at what happens here if Itanium fails.

[emil]

If AMD is successful in forcing Intel to adopt x86-64, great harm will be inflicted upon:

• HP-UX
• VMS
• Tru64 (what is left of it that is rolling into HP-UX)
• To a lesser extent, AIX-5L

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.

In other news...

[GregAllen]

Linus passed gas yesterday.

Droves of geeks were seen wafting in his wake, hoping to get a whiff.

Must be a slow day for news.

The Other Lord's Prayer?

[randomErr]

Our Linus which art in Santa Clara, Hallowed be thy name.
Thy kernal come.
Thy will be done in desktops, as it is in servers.
Give us this day our daily rpm.
And forgive us our crons jobs, as we forgive our cron jobers.
And lead us not into temptation, but deliver us from Microsoft:
For thine is the kernal, and the power, and the glory, for ever. Amen.

32 bit CPUs are here forever

[willy_me]

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.

Re:32 bit CPUs are here forever

[stripes]

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.

Read IBM's own tech specs on the POWER4, it does the POWER ISA, PowerAS, and PowerPC. They are not mutally exclusave. The PowerPC added a bunch of single pression FP, and dropped (or made implmentastion dependent a bunch of DP and other stuff they didn't think a Mac needed). I think the PowerAS has some stuff for using *huge* address spaces (useful for a capability baised system), but I don't know that much about PowerAS.

I don't think any affordable Mac is going to use the Power4, but Apple could do it for a hig end server, something like the X serve, but maybe 5 times the cost (since the POWER4 CPU is thought to be about twice the cost of the existing X serve!).

I also have my doubts about IBM putting AltiVec into the POWER4 (the did licence it from Moto though), and some real doubts about whether Apple would build a high end system with an AltiVec-less CPU.

Out of context

[p3d0]

This is entirely out of context. Linus says that there are some problems in Linux related to implementing certain 64-bit things in certain ways, partly because of gcc bugs, and so he said the equivalent of "let's hope x86-64 wins because then we don't have to think about it".

I wouldn't take this particular quote to be his definitive statement of preference for x86-64 over IA-64.

DEAR STEVE JOBS

[roca]

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

Re: The PPC eBook spec supports 32 and 64 bit CPUs

[willy_me]

No, Motorola 8XXX chips are eBook compliant chips. The eBook specs support both 64bit and 32bit cores.

The is absolutely no reason to go with a 64bit CPU unless you have to do a lot of work with 64bit integers (unlikely) or you need greater then 4gigs of memory space (more likely). The eBook spec supports future CPUs for Macintosh computers that require lots of RAM (64bit) and future CPUs for the embedded market that require very little memory (32bit). Those CPUs that are currently available are 32bit CPUs.

And yes, there was the failed PPC 620 CPU but that never really made it out into any products so there haven't been any real 64bit PPC CPUs to date (although I'm sure they're coming.)

As far as Power chips running PPC code - I don't think so, although I could be wrong. From what I understand, the PPC601 was a transition chip to the PPC architecture. It was designed by IBM and able to run much of the Power instruction set - thus making Power applications easy to port. Then came the 603 and 604 CPUs designed by Motorola. They were much different from the original 601. This is all when IBM had great plans of the PPC architecture being able to do everything and taking over 8x86 - it didn't happen. From there, the architectures diverged with PPC going towards efficiency and Power going for, well, power.

To make a long story short, PPC can _almost_ run the Power instruction set of 1990 - or at least code is easy to port. However, the Power architecture was never designed to run the PPC instruction set. A Power CPU of today won't run a program compiled for PPC.

Re:Let's look at what happens here if Itanium fail

[rodgerd]

HP don't actually have much of a problem, because Itanium is basically HPPA 3.0 with a bunch of x86 emulation stuff tacked on. HP have, in effect, gotten Intel to underwrite the development of their next-gen RISC architecture and hype it as the next big thing.

In a scenario where Itanic is a failure (ie ends up in a niche as a midrange only CPU), HP-UX and VMS are in much the same position they were before - running on an expensive niche CPU.

AIX still has POWER 4/5, so IBM don't care.

The people who are screwed are the people porting their OS to what could become an HP-only chip.

General misunderstanding on IPF (IA64) pureness.

[leandrod]

First, Itanium is the marketing name for the processor. The architecture is IPF, or IA64.

Second, it's anything but pure. It also has an IA32 (i386) compatibility mode, that kills any die size benefits of a new architecture, at least for the next few generations until IA32 really dies.

Third, even when it gets rid of IA32 compatibility, IPF may still be a pig: many people who know more about this issue than me consider it to be too complex and full of bad trade-offs, essentially stretching a good idea (VLIW) too far (EPIC).

There is the argument that RISC architectures are essentially better. Too bad IBM can't find its way to the general market, Motorola has only proprietary Apples as its venue, Sun falters in execution and forfeited popularisation, and Digital was killed by elitism.

What Linus says is not as important...

[software_non_olet]

What Linus says is not as important as the fact that his words are spread and discussed all over the internet. That's proof that we don't have a one- or two-player game any longer (Microsoft plus Intel).

It's an important power-shift, which took place. Now four players decide the further development: two OS- and two CPU- manufacturers. And to avoid deadly risks they need to be compatible to each other.

Woopy! The market is getting back it's power!

Wants Hammer to beat Pentium, not Itanium

[iabervon]

He has nothing against the Itanium (in fact, Linux runs on the Itanium perfectly well). What he's hoping for is that Hammer takes off so the non-Hammer x86 market dries up and Intel goes to an Itanium/Hammer product line instead of Itanium/Pentium. What he's worried about is 32-bit machines with large memory and disk.

Re:The problem with Hammer.

[ivan256]

More has to happen then an IA-64 price drop. (Or more has to happen to cause an IA-64 price drop, depending on how you look at it.) IA-64 is a beast. It's a HUGE chip that drinks power. The system I used last used more power then any of my kitchen appliances except for the oven. That has to be fixed. The CPU with the fixin's has to cost less then just the power module probably costs right now. Then there's intel not letting anyone actually build systems with Itanium in it. They white box the systems, and let vendors rebrand them. That's not going to go over well forever. You have to wonder what intel is hiding that they won't let OEMs build boards and systems though... What dirty little secrets does Itanium hide?

The second problem is that it's proprietary. Yes, proprietary, just like Power 4 and PA-RISC. Intel bills it as open, but if you want open you should go Sparc, MIPS, Alpha (dead soon unfortunatly), or x86. Those are the architectures that have competitive vendors manufacturing the cores. People write all kinds of software for x86. Not just desktop applications. Itanium can't get that kind of support if only Intel makes it. You'll see X86-64 in embedded devices right out of the gate. There are manufacturers DROOLING over a low power 64 bit chip to stick in their storage boxes and database servers. You won't see Itanium in there.

You have to wonder wether there are two different companies over at intel. You've got the Pentium 4, which is basically driven by the marketing department, and is a huge marketing success, but the architecture is nothing to write home about, and generally lame in the innovation department. Then you have the Itanium, which is a big grown up microprocessor that was driven by the engineers, and is going to turn out to be a marketing failure. Oh well.

Re:The problem with Hammer.

[puetzk]

5-600W is a big range. How about some real numbers just for grins :-)

As viewed from my 650VA UPS (which will tell me the wall power consumption, including all losses in the PSU etc) my dual athlon (2xMP1600) +17" monitor sits at approx 400VA load. When the CPU's idle to C2 (most of the time) it drops about 80VA, and if the monitor sleeps it dropsanother 110VA or so.

So the fixed (ie PSU+HD+video+mobo+CPU idle) comsumption+etc is about 200VA, each CPU is about 40VA (different from C2 idle to max load), and the monitor is about 110VA.

Making the (basically reasonable, though not perfect) assumption that a switching power supply's power factor is close to 1 (shouldn't be far from that I wouldn't think) 1VA=1W. If the power factor is not one, then a VA is less than a watt (ie, all my numbers are too high in that case).

So it's a good heater, but not as bad as you feared. The lights in the room are using as much power as the idling computer, the computer edges them out during a good quakin' session :-)