Inside the Itanium

vanguard writes: "Extreme Tech has a detailed overview of the Itanium. It's fairly long but it's worth your time if such things interest you."

Comments

Better link

[jeroenb]

Go here to view the entire article on a single page without all the annoying crap around it :)

Re:Better link

[Segfault 11]

... and for a recent read on Hammer, go here: http://www.hardwaremania.com/reviews_eng/hammer/ha mmer1.shtml

Of course, for some perspective on the nature of processor speculation, I point you to nearly any issue in Byte's print archive.

Re:Better link

[1010011010]

Wow, that is so poorly written!

The first article that i wrote about the processor architecture was approximately five years ago in order to estimate the present situation for the 64 bit processor market. At those days, the name "Willamette" was implicitly whispered on the sites, which were close to the chip giant, Intel. Intel had bought the production sites of Digital Corp. which was a firm with its product lines beyond its time. On the same period, we were discussing the upcoming announcement of the exciting chip K6-2. And the dream of a 64 bit desktop was even existent on the minds of IT market. I just wrote my first processor article on a 486 DX-2. At that time I was discussing the nonexistent and superior processors when measured with the glorious benchmark criteria of those days, Spec95 than my computer; lots of our crew, were just asking "... why do we need that much processing power on a desktop" scornfully. Now, I can barely put up hauling myself back from laughing, when I looked back to those swirling and blazingly fast years for processor market.

Woof! Someone help that guy get his GRE...

328 registers!!!

[chrysalis]

Wow, 328 registers. Does it mean that it will be more efficient to declare all variables in a single function than using multiple functions (due to scope of variables that restricts the efficient usage of so many registers)?

Re:328 registers!!!

[Lord Sauron]

Real programmers who had to deal with the lack of registers. For instance, take the infamous Z-80. It had only 7 general purpose 8-bit registers, A,B,C,D,E,H and L, and you could use BC, DE and HL as a 16-bit register.

It also had 2 16-bit index registers, a 16-bit stack pointer and a 16-bit program counter. Wich, of course, shouldn't be used for calculations.

So you could count the registers on your hand. Ye good ol' times.

Re:328 registers!!!

[Bodrius]

I would expect to get one hell of a compiler to optimize my code for something like that for me if it's possible.

Some programmers do not divide my code in little functions to save some register swapping, but to make it easier to read, manage, and of course to code.

Although I can see how not having to fight for your registers is a big help at the assembler level, I would be very, very afraid of someone who codes a function/method/procedure with 300 variables "to take advantage of the registers", be it C, Assembly or whatever. Fear does not always imply respect.

I would think all those registers would be much more useful in context switches and/or pipelining issues.

Say, allocate, 30 registers to each context and keep 10 contexts running on the processor without much penalty. Prepare your variables for your next few operations for each conditional outcome on the registers. Stuff like that would be more useful (and less visible) in most cases.

Re:328 registers!!!

[jockm]

7! What luxury! In my day, we had the 6502. It had only 4 registers (A, X, Y, & S), and we liked it...

Kids these days...

Re:328 registers!!!

[mgblst]

Virtual registes... also known as memory.

Try before you buy

[T1girl]

There's no guarantee that any calculations you did won't have to be redone with valid data. It's a bit of a gamble, but can pay handsomely if you speculate wisely. Architecture imitates life.

It was worth reading a long article to come across this nugget of wisdom. I think i'll embroider it on a sampler and hang it in my cube.

Dell Launches 64-Bit Workstation

[Mattygfunk]

Dell launched this 64-bit machine mid-2001. It comes with a single Intel Itanium processor at 733 MHz, 1 GB SDRAM, Matrox Millenium G450 graphics card, 18 GB SCSI hard disk drive.

The price? $7,999 at the time.

Why all the hubbub?

[PoiBoy]

...we'll evaluate the pros and cons of the "other" 64-bit processors used in workstations and servers, such as SPARC, Power, MIPS, and Alpha.

What is so special about the Itanium other than the fact that it's from Intel? We've had 64-bit processors for years now. Moreover, it's not like everyone is going to ditch the IA32 architecture overnight and go to Itanium. It seems to me that anyone who needs/wants 64-bit computing already has it.

Re:Why all the hubbub?

[tftp]

This is the opportunity to get your 64-bit computing in a beige box instead of a proprietary system. Supposedly, it will be cheaper, easier to use, and mainstream. For most people, one killer argument is "Does it run Windows?" - and you can't natively run Windows on Sparc or HP/UX... (whether you can run Win64 on Itanic is another story ;-)

Re:Why all the hubbub?

[d5w]

Alpha has no x86 compatibility, Itanic promises some.

The FX!32 emulation/recompilation system actually provided very good transparent x86 compatibility on Alpha WinNT systems. This definitely fits high on my list of Really Cool Technologies; for most programs I could just forget about whether or not they ran native. The biggest drawback was a marketing one: it wasn't hardware x86, so as far as perceptions were concerned it wasn't real. I used it on some pretty challenging apps, though, and it worked quite well and transparently.

This is actually an interesting perception issue. Itanium has hardware support for x86 and software support for PA-RISC. The original article attributes this to a lesser priority being given to PA-RISC. While that may be true, it may also be due to the PA-RISC customers having less of a "real PA-RISC" hardware vs. software hangup than x86 customers.

Re:Why all the hubbub?

[Preposterous Coward]

Note that the story says it is the first of a series on 64-bit processors. I assume IA-64/Itanium was first because it is the one most likely to show up on mere mortals' desktops a few years from now...

Not about 64 bits...

[jeroenb]

I've been looking into the IA-64 for the past year orso, and I'm convinced that on the technology side, both the architecture and the implementation are a good thing. What surprises me is that it's still taking quite some time for it to start popping up in actual production environments. Not sure what the reasons for this are.

First of all, with HP being a co-developer of the entire architecture, they are a big backer of the Itanium. So is Compaq, who sold their entire Alpha technology to Intel to focus on implementing the Itanium in all their high-end products (makes you think, was this all decided because they already knew they were going to merge with HP? Probably...) Dell is still sticking with 100% Intel, so the Itanium will be their bet for capturing more of the high-end segment. Even SGI is selling Itanium workstations (although, with the recent announcement of the MIPS-only, IRIX-only Fuel workstation, they might abandon the Itanium as well.)

So what's holding it back? I think that although there's now Linux available for it as well as a prerelease version of Windows Server along with some other systems (like HP UX) we still need to see more applications. Databases alone just aren't enough - and with the high prices of Itanium machines (the cheapest dual-Itanium 733 is around $22K at Dell, everyone else is probably more expensive) developers are not really happy about buying a couple of those machines and start hacking. So I think that because we don't see the Itanium much, developers are not investing in writing the software and business are not investing in buying the hardware.

Maybe Intel should start giving out IA-64 machines to opensource hackers and watch it fly? Where can I submit my address info? :)

Oh and about the subject of this post, the fact that the Itanium is 64 bits is not really all that important - the fact that a processor is 64 instead of 32 bits doesn't say anything about how fast it is. If you think it does, you can buy my R4400 Indigo2 for $10K :)

Re:Not about 64 bits...

[d5w]

So what's holding it back? [...] we still need to see more applications.

What applications, though? In particular, what applications for which Itanium would have an advantage? Whether or not the architecture is a good idea long-term, the current implementation doesn't offer a compelling performance advantage for any one application. What kind of software could make the current hardware sell?

Re:Not about 64 bits...

[Florian Weimer]

So what's holding it back?

For real-world numerical applications, using state-of-the-art Intel compilers, the Pentium 4 is faster than the Itanium. Of course, people still use the Itanium because of its substantially larger address space, which is a very, very significant issue. And we can expect the IA-64 architecture to catch up as compilers improve, as it is common with such architectures.

Re:Not about 64 bits...

[sjames]

Unproven platform.

Whats worse, the next release will require a new motherboard, so there's no hope of getting used to it now, then a simple upgrade once the bugs are out.

Re:Why this strange name ?

[Brento]

Does anyone here know why Intel named this processor with such a strange name ? Everybody associates Itanium with Italy - a country with Mafia

Uhh, no, try titanium, a material known for its phenomenal strength. Lop off the first letter, and you have a word that calls to mind the Internet, Intel, and titanium. Pretty slick name, if you ask me.

The sad thing is that titanium has gotten to the gimmick level lately. They use it in everything from sunglasses to golf balls to notebook cases, and it usually isn't even the right material for the job. It's just used for the "coolness" factor....

What about power / heat ?

[redelm]

A nice architectural overview, but there's no mention of power. IIRC, Itanium sucks back 125 Watts!

Power/heat this high gives system designers problems, plus it can't be easy getting ~100 Amps to&from a chip.

Otherwise, AFAIK, Linux has working ia64 so code size can be compared. I'd expect 4x x86.

Re:What about power / heat ?

[CMiYC]

Yeah it is a power hog. For Merced there is a power pod that goes next to each "processor". That pod provides the power to the processor only. Then from there, there power is distributed to the L3, PAL, Core, etc. I'd imagine on the processor's core chip the power is distributed by a signfinicant amount of pins. Otherwise it'd be a bear to get the power evenly to different areas of the die.

or my R10K Indigo2 for $20K...

[green pizza]

Oh and about the subject of this post, the fact that the Itanium is 64 bits is not really all that important - the fact that a processor is 64 instead of 32 bits doesn't say anything about how fast it is. If you think it does, you can buy my R4400 Indigo2 for $10K :)

Or my R10000 Indigo2 for $20K... at least it runs "IRIX64" the 64-bit kernel and the 64-bit ABIs.

elwood 6# uname -aR
IRIX64 elwood 6.5 6.5.15m 01091821 IP28

AFAIK, the only SGIs that use the R4400 in a 64-bit manner are the Challenge L, Challenge XL, and (original) Onyx. R4400 in desktop machines is limited to 32-bit support for memory contraint issues. 64-bit on the desktop from SGI requires an R8000/R10000 based Indigo2, R10K/R12K/R14K Octane/Octane2, or R14K Fuel. All other desktop configurations are limited to O32 and N32.

Re:Why this strange name ?

[Spencerian]

I'd have to disagree with the use of titanium in some cases. True, a lot of companies are using the name for the cool factor, but Apple's application of titanium as its outer case for its professional PowerBook line is both aethestic and functional.

The PowerPC G4 chip is a hot beast (nothing like the P3 or P4, but hot enough) that the titanium is used in part as a heat sink. Apple's application of the metal seems to get lots of oohs and ahhs as a result of this blend.

Re:As a complete processor lamer

[d5w]

What I would like to see is a bullet pointed list of advantages put in executive summary style, dumb-down, type!

Advantages over other existing 64-bit processors:

• It's got the Intel name on it, and will be marketed accordingly.
• It'll run Windows.
• It hasn't been dead-ended by its manufacturer.

Advantages over x86 processors:

• It's slightly better for high-performance floating-point computation.
• It makes a better space heater.
• It'll keep determined assembly-language hackers out of your hair for a while.

I think that about covers it. Not all of those will be advantages for every consumer, of course, nor do all the advantages apply to every competitor.

What's the point?

[4im]

Except for the Itanium coming from Intel, what's the point? This is a prototype for a new architecture (IA64), prototype proven to be seriously lacking in speed, stability etc. I got to see a dual Itanium prototype from HP a few months ago, and all the comments I got about it were that it essentially sucked.

Really, if you need 64 bit, why not just go and get yourself some UltraSparc, Alpha etc.? I have gotten myself a used Ultra 30, will soon get an used AlphaServer, and I sure don't need to go buy an expensive, unstable processor that's not even got decent compiler support yet.

And if it has to be IA64, at the very least wait for McKinley - HP's engineers are supposed to be doing a much better job of IA64 than Intel did. Or even wait for the version after McKinley, which is supposed to profit from good ol' Alpha.

Re:What's the point?

[CMiYC]

And if it has to be IA64, at the very least wait for McKinley - HP's engineers are supposed to be doing a much better job of IA64 than Intel did. Or even wait for the version after McKinley, which is supposed to profit from good ol' Alpha

The point of this article is to introduce you to the IA64 architecture, which McKinley and Madison are going to be based on. The point of developing for Itanium/Merced is to learn how IA64 is different from IA32 so that when you do a McKinley platform you are ready and not fighting with as many "what the hell is it doing now."

I've seen many protoytpes as well from HP and others and the reponse is not "it sucks." The response is "wow, we've got a lot of work ahead of us."

wrong direction?

[markj02]

Itanium is built around the notion that many of the hard decisions about how to execute code efficiently should be handled in software (mostly, by compiler back-ends). I think this is not the right direction to go into. It means that every single compiler back-end will have to re-invent the wheel. Most likely, there will only be a small number of compilers that will do a decent job, and a lot of languages won't even try. That's fine if you think the world consists only of a bunch of SPEC benchmarks implemented in C/C++, Fortran, and Java, but it will make life even harder for non-standard languages or non-standard applications. And Itanium's implementation of VLIW seems particularly complex.

Software is by far more costly and complex than processors these days, and we just don't need extra complications in the form of processors that shift even more complexity into software.

I can't pretend to know what a "good" 64bit architecture should look like. But for the time being, something like Alpha or AMD Hammer seems like a better choice to me. And even Intel seems to be reconsidering and keeping a 64bit version of the Pentium as a backup strategy.

Re:wrong direction?

[Mydron]

You've missed the point.

Complex compiling issues are NOT a result of CISC or RISC in this case. In fact, RISC is far easier to write an efficient compiler for than CISC. The instructions offered by RISC more closely mimic the kinds of basic operations compilers manipulate in the very back end of compilation. Register sets are usually general and very orthogonal, compared to CISC (Intel in particular) where you have very few registers and they all have special meaning depending on context.

The complexity in building compiling tools with respect to the itanium is all about VLIW, parallelization and scheduling. These are incredibly complex topics with many subtle features that make optimization and analysis very difficult.

Also, think again if you think compilers are written once for an achitecture and then set in stone -- 'once the damn thing is done' it definately will not be done. It will probably be buggy and poor at doing these new complicated tasks compiler writers have never had to do before. It will likely take a few iterations before the compiler tools start to show off the architecture. The question is which will come first, the latter or industry's frustration with poor performance out of expensive silicon.

Re:wrong direction?

[markj02]

The main bottleneck of modern microprocessors is, in fact, the extra space and heat produced by the complex logic you defend.

The problem doesn't magically go away by shifting it into software. A static compiler cannot do instruction scheduling and parallelization correctly--you need runtime instrumentation and JITting. The end result is something that likely performs more poorly than if you had let the processor do this.

Nowadays a CISC processor waste more time translating the bytecode and executing the microcode that anything else

CISC vs. RISC has nothing to do with it.

But think : how many compilers was written in the computer history, and how many applications was written with these compilers?

Not nearly enough compilers have been written.

This ratio will prove that it's worth the trade. Of course compilers will be more complex and hard to code, but once that damn thing was done, it was done.

Yes, if you are happy muddling through with C and C++. Itanium will further cement the dominance of languages that we already know to be absolutely lousy from a software engineering point of view, because almost nobody will be able to make the investment to write a competitive compiler for any other language.

compiler technology crucial

[mrm677]

Itanium is making the compiler do alot of work! This presents a gigantic challenge for compiler writers. My concern is with GCC. We all know that GCC does not produce the tightest, fastest code. For IA-32, this is not a big deal because there is only so much optimization that can be done with that ISA (instruction set architecture). However with Itanium, the compiler will probably affect runtime execution speed by 100% or more. Will the GCC people have the resources and expertise to handle IA-64 (Itanium)??

So what's holding it back?

[dpilot]

How about the fact that VLIW (or EPIC, if you prefer) compiler technology really isn't there yet for general purpose problems? Maybe you can write a program for EPIC and get it to scream, but simply recompiling the ray-tracer (or what-have-you) you already have just won't show much. Take a look on comp.arch for more, especially under X86-64 for evolution vs revolution opinions.

compilers harder to write

[markj02]

Let me try and get this point across again: writing compilers for the Itanium architecture will be a lot harder than writing compilers for other architectures. The reason is that the compilers need to make even more guesses about what kind of parallelism is possible and what instructions can be scheduled together. The programmer can't really help either, since trying to hand-optimize code for VLIW is just too tedious. This will mean that Intel will make the investment, and we will likely get, decent compilers for C/C++, Fortran, Java/JVM, and C#/CLR, but for any other language, it will be even more of an up-hill struggle. And even in those languages where good compilers exist, if you do something that the compiler doesn't quite understand, it may make the wrong assumptions and generate poor code.

Altogether, that can't be good for the industry in the long run. We need more, not less, support for new software architectures and languages. Instruction scheduling and parallelization are things that a processor can handle much easier than a static compiler because the processor can efficiently keep runtime statistics on what a program actually does.

Potentially a better approach to me appears to be hyperthreading, which redefines the problem. No, individual threads won't get very high performance, but code generation is pretty easy, and (unlike VLIW) the programmer can take explicit control of parallelism at a higher level through threads. To me, that seems like an overall better approach.

Can anyone understand this?

[Pedrito]

I've done my share of assembly language, from 8-bit Ataris to 32-bit Intels, to IBM/390 mainframes.

I can't even conceive of having to write assembly code for these monsters. Anyone happen to browse through the instruction set reference? All 900+ pages of it? It's all cryptic as hell. I could sooner build a rocket bound for Pluto than write a simple recursive factorial program in IA-64 assembly.

I sure hope someone can figure it out. I doubt I'll be doing any assembly optimizations in the future.

Some weirdness, but good

[be-fan]

First thing that occured to me is that the arch is a little weird in places. No integer multiply, wtf? Of course, then it occured to me: who uses integer multiply? The main reason to use them would be mainly in rasterization code in a graphics pipeline. Since integer-based rasterization went out with MMX, this doesn't matter. Overall, the arch seems pretty clean, a hell of a step up from x86, anyway. And, the initial performance seems pretty good, so it seems to work. While the whole EPIC thing could mean hell for compiler writers, remember that Intel's ICC has been doing parallization on x86 procs for years now, and does a damn good job of it. I can't wait for Deerfield to come out so I can get to chose between that and a K8 for me next PC ;)

cache hits

[johnjones]

the real problem for intel is that the arch does badly for programs that are not cache hitters

they took one look at the people trying to do predictive memory loads and decided not too. this was a LONG time ago and now people have solved the problem so that most of the time you can get things from cache

IA64 fails to get things from cache too well (one of the reasons why they stuck such a large one on) so suffers from the latencey problems more than most

simple

regards

john 'try runnning spec marks on it' jones

Overview? How about Autopsy...

[HiredMan]

HP decided as early as 1996 that the then "Merced" project would not overtake their PA-RISC arch and essentially walked away from the the project.

Years late the "Itanium" finally ships (although no one buys it) as Intel says, "But wait for McKinley! Then it will really work!"

The McKinley is the product of the "rethought" Merced project. McKinley is shipping later this year - with a completely different socket system so even the arch surrounding the "Itanium" is dead in the water.

Let's compare this to the REAL competition:

IBM Power4 1.3GHz - shipping for a while now:
SPECint2000 = 814 SPECint_base2000 = 790
SPECfp2000 = 1169 SPECfp_base2000 = 1098

Sun UltraSparc III Cu 1.05GHz:
SPECint2000 = 610 SPECint_base2000 = 537
SPECfp2000 = 827 SPECfp_base2000 = 701

Even the best Itanium 800Mhz reported int numbers are:
SPECint2000 = 365 SPECint_base2000 = 358
(Same box) SPECfp2000 = 610 SPECfp_base2000 = 526

Even if the McKinley (which doesn't ship for 6 months or so) produces double the Itanium numbers it'll still lag the currently shipping Power4 chips.

Remember the hype and FUD surrounding the launch of the "Itanium" chip that eventually hasn't even caused a ripple in the marketplace? Intel has sunk billions into this EPIC project and refuses to let it go even though it's years late so far hasn't produced the clear advantage over the RISC arch it was supposed to make obsolete. In many cases the "consumer" chips continue to make better results than the "server" chip series - and with AMD knocking on Intel's door throttling back production/performance of the consumer ship is not an option.

Will the McKinley better than the Itanium? Certainly.
Will it be compelling? Wihtout Intel behind it - probably not. (Alpha was the clear performance winner for so long but couldn't get any traction.)
Is VLIW^H^H^H^H EPIC the future of computing? "Answer unclear... ask again later." ;)

=tkk

Re:Overview? How about Autopsy...

[HiredMan]

As for your SPEC figures, you could have at least made your post worthwhile by not fudging the numbers to make the Itanium worse than it actually is

I didn't. These are the numbers from official submissions to the spec organization. (If they can't bother to submit results then they don't count.) I took the machine from with the HIGHEST Int performance - as I said in my post. The FP is the result for the same machine - as I said in my post.
There is a >700 SpecFP machine claimed by Dell but there is no corresponding SpecInt submission. I think Intel claimed nearly 800 Spec2000FP for the Itanium but no one else has been able to re-create those results. That's why non-submitted results don't count.

Don't write off an entire architecture because you didn't like how the experimental implementation came out.

But it wasn't supposed to be a proof of concept chip. It was supposed to be the future of computing.

An exec actually admitted this in 2000.

Which is at least 3 years after they knew it. Intel instead spread FUD around while refusing to talk performance numbers.

From Intel Press Release:
SANTA CLARA, Calif., Oct. 4, 1999 - Intel Corporation today announced it has selected Itanium(TM) as the new brand name for the first product in its IA-64 family of processors, formerly code-named Merced. The Itanium brand extends Intel's reach into the highest level of computing enabling powerful servers and high-performance workstations which will address the increasing demands that the Internet economy places on e-Businesses. "The Intel Itanium processor represents a new level of processor capability that will be the driving force for the Internet economy,"

Ummmm... okay. I see, by "highest level of computing" and "new level of processor capability" they meant "proof-of-concept place-holder chip". It's all clear to me now...
The full text is here on Intel's site since you seem to think I make this stuff up.

Now McKinley is supposed to be the next, big thing.

From an article about McKinley previously on /.
"Applications will be about one and a half to two times faster than what you get on a (current) Itanium," said John Crawford, an Intel fellow in the enterprise platforms group.

The additional bus and processor speed and 3 megs of on-chip on speed cache should deliver nearly a 50% boost all by itself. If the "new" features of the McKinley don't add much more beyond that then where are they going?

Forgive me if I appear skeptical...

=tkk

it's always been about the compilers

[jrst]

Many of the comments about compiler technology in this thread could be taken verbatim from discussions about RISC architectures 20 years ago. Or from the HLL (high level language) architecture discussions 30 years ago. (Anyone remember the cries for "closing the semantic gap" between processor's and languages? No? Point made.)

Hardware is getting more complex; it takes more sophistication to deal with it. Binding a (general purpose) processor to a language in order to make language implementation easier is exactly the wrong way to support a wider variety of languages. Making the most of a processor's capabilities is what compilers are for. That's what compiler writers get paid for.

That's not to say I'm in love with the Itanium. At first glance I found it a baroque rehash of old ideas. But time--and compiler writer's--will tell.

A visionary's gutfeel regarding 64-bit widespread

[pinkpineapple]

When Steve Jobs was asked about what he was envisioning regarding 64-bit processor adoption (related to the fact that at that time, IBM came out with the Power4 kick ass cpu), his reply was that it would take about 10 years for the common of the mortals (you and me mostly, but not him :-) to see 64-bit systems on the shelves at Fry's or CompUSA.

Given that it was coming out from the mouth of the CEO of a company that :
- can afford the move quickly and nicely (PowerPC architecture is clean compare to IA-64 + x86 and is 32-bit backward compatible).
- had successfully shifted the kernel to a clean replacement (less kludges) allowing the transition in a blink of an eye (ok, maybe 6 months)
- has a park of installed machines in places like labs (see gentech), and design studio.
- runs applications that would benefit the most are all in the Apple camp (A/V and number crunching apps like photoshop, maya and final cut)
- develops a big chunck of the major apps for its platform leading the way in term of design and adoption of new tech.

it would seem that we have about 8 more years of 32-bit glory or galore in front of us, before the current cpu architectures get displaced and eventually die.

Which 64-bit architecture will succeed is not clear today. Knowing that MS doesn't rush their OS out of the door to support the IA-64, it seems to be a little premature to tell.

PPA, the girl next door.

Gad, what a turkey

[Animats]

I can't see why Intel bothered with this thing. Intel pioneered mainstream superscalar out-of-order machines with the Pentium Pro/II/III architecture, which made it possible to make CISC architectures go fast. That was a major achievement. It made classic RISC obsolete - why put up with the code bloat?

Then came the Inanium. VILW, code bloat, ugly architecture, requires near-omniscience from the compiler, very tough to program in assembler, a power hog, and with mediocre performance. If anybody else had launched this, it would have died before first shipment. As it is, it's dying anyway. Dell dropped their Itanium workstation recently. The Itanium may end up as a niche product, like the forgotten i860, i960, and iapx432 processors.

I'm hearing rumors of a new 64-bit machine from Intel that's basically an improved x86, like the AMD Sledgehammer. That may be what actually gets used.

Re:Gad, what a turkey

[Rasta Prefect]

Granted, this needs improvement, but x86 is hardly a prize either. The architecture of the Pentium Pro and up screams kludge. Huge amounts of circuitry that do nothing but break up CISC instructions into something resembling RISC so that they can be executed at reasonable speed. x86 didn't beat CISC because it avoided code bloat, (Does anyone eve notice code bloat anymore? I mean most of the world is running Word processor that consumes 32+ megs of RAM, who are we kidding?) it won for the same reason Windows wins, which is because it runs all your stuff. Installed user base. It was compatible with what had come before, and no one wanted to buy new programs, so we've stuck with it. It's like an AMC Gremlin with V12 engine welded onto the roof because you didn't want to have to move your stuff out of the trunk when you move your stuff. And to steal somebody eles's analogy, that V12 has uses side-injection to remain compatible with your old Model-T. I mean, segmented memory architecture? Please.

So what if you can't write assembly to make your code faster. Aside from the "Real Programmers don't eat quiche" mystique, this is a problem why? You probably can't beat a good C compiler on a P3 or P4 either. With very few very specialized exceptions, the compiler is smarter than you are. Granted, it's slow now, but this is the first generation of the chip. With some architectural improvements(please, for the love of god do something different with the cache!) this could be a pretty decent chip, and one that will still run your old apps.

Re:Gad, what a turkey

[roca]

> Does anyone eve notice code bloat anymore?

Your instruction cache does.

Re:Gad, what a turkey

[timmyd]

even though the IA-64 arch does seem to have some weird stuff into it, i wouldn't call it UGLY especially when comparing it to the IA-32 "architecture" (or rather lack of it.) and who programs in assembler nowadays? (excluding the MMX/SSE stuff which however is a direct consequence of the crap fpu on IA-32)

IA-64 still has backwards compatibility with ia-32, which has realmode, v86, and protected mode. that makes the ia-64 a mess to start with. compilers still generate assembler in some cases and some people have to use asm for low level things in the kernel and doing things that you can't do in C, like calling software interrupts, which, by the way, requires that you enter either v86 or real mode which isn't as simple as changing the PE bit. you have to setup the stack, and memory segments again and real mode can only physically access 2^20/1024/1024=1 megabyte of memory at once. maybe if intel would stop building on their old crap the whole thing would get a little simplier.
but i guess it would be boring if everything was as simple and stable as a calculator.

Re: Bold and Italics, what's the point?

[CMiYC]

As far as I can tell, current Itanium stuff is a mere curiosity.

Well right there you have already invalidated the rest of your comment. Intel is not going to have to do anything to get their IA64 architecture moving.

As announced, HP's new PA-RISC chipset will support both McKinley and their RISC processor. Sounds crazy but HP is doing it.

Furthermore nobody and I mean nobody is developing anything for AMD's 64bit systems. On the other hand I have seen significant interest in McKinely. True enough, Merced is just considered a development platform and is pretty much dead in the water. I work for a test and measurement company and I deal directly with our front side bus solutions. You are wrong. AMD is facing the same problems in the IA64 arena that they are in the IA32 arena. Intel's chips say Intel and theirs say AMD. So everybody is ignoring them, for now.

This is not to say that AMD can't come in beat them. I am just saying that Intel's solutions are already in development in many of the high-end server labs. I haven't seen a single group working on AMD's 64bit proc, nor have I been asked if we plan on supporting it.

Re: yeah

[CMiYC]

I sure hope someone can figure it out. I doubt I'll be doing any assembly optimizations in the future.

I've had to do worse, our logic analyzers have to decode the bus traffic to figure out what was going on. As you can imagine, the fact that 1 OP code could mean 4 different thigns depending on when it shows up (or what happened before it) poses a significant challenege. You might say "big deal." Sure, big deal, if you are developing a system. We have to be able to provide tools that are bug free BEFORE the first silicon hits market. That way when a guy in a lab encounters what looks like a bug isn't fighting our mistake.

I fear one day we are going to get to a point where we can't provide a solution for hardware engineers to probe their system with.

Try out Linux Itanium on IA-32 systems

[mbalma]

If you want to try out Linux on the Itanium architecture using an IA-32 system go here. You can download a simulator and a development environment at no charge. HP released this SDK in 2000 to help developers before systems were available. David Mosberger (maintainer of IA-64 Linux kernel) developed the SDK along with Stephane Eranian. It's still a good option if you can't get access to a system.

If you want to know more technical details about Linux on the Itanium Architecture, David and Stephane just released a book "IA-64 Linux Kernel: Design and Implementation". David was signing copies at HP's booth at LinuxWorld NY.

Intel's compiler writers.....

[zerofoo]

Lucky for intel, they do have a very talented bunch of compiler writers. Their work on P4 optimizations basically saved the P4 from itself. The problem is getting the rest of the complier world to support Intel's new architecture. Like them or not; Visual C and GCC are hugely popular, and until those guys support Itanic, Intel won't sell many of these newfangled processors.

-ted

Intel's next chip will be...

[Alsee]

Unobtainium

-

Re:Why this strange name ?

[Preposterous Coward]

Don't forget credit cards. A while back I got a solicitation for a "titanium" credit card. I guess they decided that with everyone giving away platinum cards, they needed a more exotic-sounding metal. It's too bad I know that titanium is actually much less exotic and expensive than platinum or whatever.

Now if it had been a rhodium or palladium Visa card, I might've thought of it differently...

Re: Bold and Italics, what's the point?

[roca]

> Furthermore nobody and I mean nobody is
> developing anything for AMD's 64bit systems.

It doesn't matter. AMD will sell plenty of Hammer chips in their usual markets, who will just use it as a faster 32bit x86 chip. (Just like the 386 was used as a faster 16bit chip when it came out.)

BUT one day someone will wake up and realize that Hammer makes for fast, cheap, cool and backwards compatible servers. And then Intel will release their secret x86-64-compatible CPU, and IA64 will be cancelled.

It's different, not better

[Animats]

Part of the idea behind the Inanium was to make it uncloneable. The business concept was to use lots of new ideas, useful or not, thereby providing intellectual property protection. This would prevent low-cost clones and allow Intel to get their profit margins back up.

This is good for Intel, but not for anybody else. Go back and look at Intel CPU prices from just before AMD processors caught up.

And that's the real reason for the Inanium.

No $64,000 question

[MarkusQ]

Hang on, there is no $64,000 dollar question, it is an urban myth.

I believe that you are mistaken. There are many people still living who remember it and you can buy video tape copies of the show. This seams a little much for "an urban myth"

-- MarkusQ