Intel's Answer to AMD's Hammer - Yamhill

bdolan writes: "Today's San Jose Mercury News is reporting that Intel is going to put a 64 bit architecture extension in upcoming Pentiums if it turns out the Itanium doesn't take off. Hmm. Apparently they intend to only turn this on if AMD's 64 bit processor make major inroads against the Itanium architecture. Aren't we glad that competition is keeping everyone on their toes."

Comments

Uhh..naming?

[Mahtar]

AMD Guy: Hehe..check out my incredible new processor. It's called the Hammer! What do you have in your box?

Intel Guy: Oh..er..I have a *unintelligible*

AMD Guy: What is that? Mumblican? Speak up!

Intel Guy: *coughYamhill*

AMD Guy: YAMHILL? Buwhahahahaha! Intel marketing loves you!

Intel Guy: *cry*

Re:Uhh..naming?

[djoham]

There actually is a basis for this name. Intel has a large presence in the state of Oregon and has a tendency to give their products code names from that state.

For example, there's the Willamette (a major river, incidentally one of only a handful in the world that run south to north), the Klamath (a county) and the Deschutes (another county and also a national forrest).

There may be others, but they don't come to mind at the moment.

As a former Oregonian, I find this kind of cool...

Best regards,

David

Re:Uhh..naming?

[suss]

There actually is a basis for this name. Intel has a large presence in the state of Oregon and has a tendency to give their products code names from that state.

I can't wait for the beaver... all 64 naughty bits of it!

Other Links

[4of12]

This has been the focus of some stories at the Inquirer as well.

Personally, I thought that Intel would have been in a good position to just relabel the Alpha 21364 as IA64 and be done with it.

Multiprocessor?

[johnburton]

I always wondered why they didn't just put three or four processors on a single chip and have instance multiprocessing. I'm sure they would be able to share some of the components that way and reduce the transistor count below what several separate cpus would costs.

And interprocessor communication and cache coherency control would all be on the same chip and so probably easier than normal multiprocessor design.

There is probably a good reason I don't know about so it's a good thing I don't design cpus for a living.

If...

[IPFreely]

Intel is going to put a 64 bit architecture extension in upcoming Pentiums if it turns out the Itanium doesn't take off.

If it doesn't take off? It takes years to develop that kind of new architecture. By then AMD will have it swept.

Don't follow AMD. X86-64 is a follow on architecture, and whatever Intel comes up with wouldn't be much better even if it was different. Computers need to move away from that old decrepid IA32 instruction set eventually.

Intel has a new road and it is not entirely stupid. They are facing the same problem that everyone trying to compete with them has been facing for a long time: compatibility with the installed software base. Either you're compatible and can run IA32 or you're not and you have to come up with lots of other software (enter open source).

Eventually, CPUs needs to move to better architecture. backwards compatability is good during transition, but shouldn't hold you back too much. Go forth Intel and do what everyone else has had to do for a long time, (gasp) struggle for market share.

Re:The free market at work

[Pyromage]

It seems your trying to draw a parallel here to the MS case. That is not entirely possible in this instance.

There is one critical difference: it's possible to clone an x86 processor. They are standard and well documented.

You can't clone Windows. It is only partially open, with closed file formats and APIs all over the place. Open APIs are often not documented well, or may have undocumented bugs which applications depend on.

It is possible to make a chip that will run all the same applications as Intel's, and to do so in a reasonable timeframe. However, Wine and LindowsOS are clear counterpoints to that, showing that that CANNOT be done with an OS.

Yamhill

[sben]

For those who care, Yamhill is a small town WSW of Portland (the little red star at the lower left).

Fascinating info can be found at cityofyamhill.com, naturally.

Intel naming.

[Anonymous Coward]

I am laughing at there choice of the yamhill river for the naming. I live about 3/4 of a mile from the river. They find two headed fish in it, I don't even want to know what will be found in the intel processor.

Not exactly

[autopr0n]

The diffrence between the pentium and the p-pro are rather minute when compared with the diffrence betwee any pentium/486/386/etc chip and the Itanium. To really answer your question, though you kind of have to look at the history of the whole thing.

To start things off, intel releases the 8086, and the cheaper 8088 (8086 with a 8, rather then 16 bit bus interface). And thus begins the x86 era.

A little later intel decides they need a 32 bit CPU, but rather then design a totaly new chip, they just add a bunch of extensions to the 16 bit one. They call this new chip the 386, and it's supposed to revolutionize everything. The chip is totaly backwards compatable with the old 8086's and 286s (so the old register AX becomes EAX, but you can still access the first half as AX).

for a long time (windows 3.1) most software still ran in 16 bit mode, not really utilizing the software. IIRC It wasn't untill windows95 and NT started getting used that people really started to take the full potential of their machines in every day tasks.

Now, this is also around the time of the Pentium and the Pentium pro. The pentium ran both 32 and 16 bit software quickly, but the ppro ran 32 bit software faster, and 16 bit software more slowly (of course, the p-pro core became the pentium II, then the pentium III and ran at much higher clockspeeds, so it eventualy became a non issue, a 1.3ghz pIII is going to crunch 16 code faster then a pentium233mmx no mater what :P)

Now, when you look at what AMD is doing and I guess intel now with their rather odly named Yamhill is taking the orgional design and adding 64bit extensions the way they added 32 bit extensions to the 286. EAX becomes RAX, and you can get at the first half by calling it EAX and the first quarter by calling AX, etc.

Itanium is a totaly diffrent thing, it's a whole new system with x86 support tacked on extra, rather then tacking on 64 bit support to an aging archetecture.

Hrm, I hope that explains things.

Re:Not exactly

[tempmpi]

You are right: the p-pro core became the pentium II.
But the PII doesn't suck at 16-bit code because Intel done some little changes in the p-core so that the PII could crunch 16-bit code much faster. In fact there was only one problem with p-pro core design that caused the p-pro to suck at 16-bit code. The p-pro misses the segment register caches, that were included in the pentium and reincluded in the pII. Because of that 16-Bit programms that use segments will generate one additional memory access for every memory access they were doing. When Intel saw that that there was a need to run 16-bit programms they reincluded this caches and because that the performance of the pII doesn't suffer anymore from 16bit code.

There is also something important to note on AMDs x86-64 extensions. On the integer side they are really compareable to the 32-Bit extensions made in the 386 but the x86-64 extensions also change the working of the floating point unit.

All current x86 CPUs could reach very good benchmark scores on benchmarks that work mostly with integer numbers but they get bad scores at many benchmarks that use floating point numbers a lot. Intel and AMD are already trying hard to make their FPUs faster, but they couldn't reach really good improvements because the x86 fpu intestruction set isn't good for modern cpus. The x86 fpu doesn't have a normal register set with registers that could be addressed individually but it uses an register stack. You could only address the top of the stack(TOS), the register under the TOS,TOS-2 and so on. If you used a RPN calculator, you know what i'm talking about. This design isn't that bad if you execute one instruction at a time. It even makes programming fpu asm a bit easier.

The problems came with the introduction of cpu that executes more than one instruction at a time. To make full use of that feature the compiler or assembler programmer must often interleave multiple calculations. The fpu stack is very hostile against such optimizitions.

Because of that AMD has done a almost complete rework of the x86 fpu instruction set that matches the internal working of moderne fpus much more.

This is bad news for Intel

[bhurt]

Everyone remember the "Intel Inside" marketing campaign? Anyone remember "Authentic AMD"? The Intel Inside campaign was based mainly on FUD and Intel's control over the x86 processor. Since the x86 was a "defacto standard" defined by Intel, only Intel could gaurentee that it followed the standard. If you used other people's CPUs, they might work, but they might not. Better safe than sorry, right?

If Intel publically implements the x86-64 architecture, while more-or-less simultaneously dropping the IA64 architecture, it will be diaster. It would be publically admitting, in deed if not in word, that AMD controls the future evolution of the x86, not Intel. The best Intel could hope for would be for AMD to gain an incredible amount of credibility- which translates as sales in the lucrative but conservative buisness markets. Even worse, the current positions of AMD and Intel might even be reversed, with AMD being perceived as the flagship processor company and Intel the clone maker.

Going to 64-bit is rapidly becoming not an option. Many desktop systems are having a gigabyte of memory installed. Even x86 servers often have three gigabytes of ram installed. The server market is even worse off than the desktop market, as all the ram is generally given over to a single application (Exchange, or a database, for example)- and a 32-bit processor simply can not access more than about 2-3 gig of memory in a single application. The big-iron Unix cpus (Sun's SPARC, HP's PA-RISC, IBM's Power-4, etc) all went 64-bit years ago. It's not unusual to see even "moderate" servers of 4-, 8-, and 16- CPUs having tens of gigabytes of RAM already. The only market that still supports 32-bit CPUs is the embedded market- not a market Intel has ever displayed much interest in.

I figure that the x86 has maybe 3 years to go 64-bit across the board, or we'll be facing another 640K like situation. 3 years is two Moore's Law generations- meaning the people with 1G of memory today will be wanting 4G in 3 years, and the people only getting 256M today will be getting 1G. They'll continue to be hurt in the server market, but they won't lose much in the desktop. Unfortunately, to be 64-bit across the board means the high end needs to be 64-bit within about 18 months (allowing for a Moore's Law generation to push the 64-bit CPUs down the price scale).

Hammer is in a position to do that. McKinnley is the succeed or die point for the IA64. To use an analogy, Intel will have run out of runway- either it flies, or it'll hit the trees.
The successors don't matter- if McKinnley doesn't succeed, Hammer will be there to take the sales. If Intel stays in denial and doesn't offer a viable 64-bit path, they'll be in worse shape than simply admitting that they lost.

At that point, the best thing Intel could do is roll out a Hammer of their own, and plan on less than 50% market share.

Brian

Re:"8086 took 3 weeks to design"-easy to believe!

[Detritus]

I think it is very unlikely that the 8086 was designed in three weeks. I used to have a book on the 8086, written by the chip's architects.For what the chip was designed to do, they did a good job. Intel thought that most of the software for the chip would be written in PL/M or Pascal. The segmented architecture was a good match to those languages. The floating point hardware (8087) was a major advance, being the predecessor of IEEE floating point. 8080 programs could be mechanically translated into 8086 programs. The 8086 supported all of the peripheral chips that had been designed for the 8080.

Stop making fun of the names

[pclminion]

First you made fun of Tualatin -- a shitty city to be sure, but also the name of an Indian tribe and a river. I work in Tualatin.

Now you are making fun of Yamhill. Not only a river, but a city as well, and a major east-west running street in Portland. If you ever come to Portland, check out Yamhill street. Lots of cool stuff, nice place to get drunk.

Would everyone please lay the fuck off already. We're proud of Intel around here and we're proud of our rivers, cities, and streets. I don't make fun of people who live in New York, even if "York" is a pretty stupid sounding word.

Grow up, assholes.

The Inanium, or why VLIW sucks

[Animats]

The basic problem with the Itanium is that it's a Very Long Instruction Word machine. VILW machines require a compiler that can recognize parallelism, which is hard. Worse, the code has to be such that explicit parallelism helps. If there's a lot of branching, the compiler has to be incredibly smart (and may need profiling data feedback) to do a good job. I went to a talk by the HP compiler guys who were trying to do an optimizing Itanium compiler, and they were having real problems.

VILW is an old idea. It's been obsoleted by superscalar processors. It turns out to be better to find parallelism at run-time in hardware than to find it at compile time.

The real reason for the Itanium was to have something that had some intellectual property that AMD couldn't clone, allowing Intel to crank up the price and get their margins back up.

As for the AMD 64-bit machine, it's entirely vanilla. It's very x86 like, with the same instruction set, a few more registers (yay!), and of course the registers are longer. It has all the obvious backwards compatibility stuff. It comes up emulating a 32-bit x86 machine, so old OSs will run, but can be put into 64-bit mode. In 64-bit mode, it can simulate multiple virtual 32-bit machines, so you can have a 64-bit OS running both 64-bit and 32-bit processes. (Run 32-bit Windows under 64-bit Linux!)

Wierdly, the x86 instruction set isn't viewed as that bad today. The variable-length instructions aren't that much of a problem to decode any more. Speculative decode takes care of that. One big advantage of RISC architectures was that making all the instructions the same length simplified decode and allowed more look ahead. That's a dead issue. Making the instructions all the same length causes about a 2x code bloat, which is now unnecessary.

The other big RISC advantage was having lots of registers. Register renaming and caches have killed that advantage. Today, a register is just a short name for a recently referenced variable. There are far more registers inside a Pentium Pro and later than the few explicit ones you can mention in x86 code. In fact, one advantage to not having too many registers is that it shortens subroutine calls and context switches. The machines with huge numbers of explicit registers, like SPARC machines, put a lot of effort into saving and restoring them.