Future Intel CPU: Nehalem

[alexsok]

http://www.aceshardware.com/

Doug Carmean, an architect who worked on the Pentium 4, as well as several other Intel CPUs, makes note of Nehalem in this interview:


RS: What project followed the Willamette project?

DC: I had about a one or two-quarter stay on a project called Prescott, which was a follow-on to Willamette. It was basically doing some performance enhancements and taking it to the next generation process. Within the last year, I’ve been leading the architecture team that’s defining the next all new processor, a processor called Nehalem, and that’s been the focus for the last year. So that could be Pentium 8, or something like that, in the year 2004. So we’re a taking from scratch approach to microprocessor design.

So what do u guys think? What major things still need to be overcome in the CPU area? Perhaps they are moving from x86 all together? Any other ideas are appreciated!

P.S
Forgot the roadmap!

 

[Saem]

Well expect a really long pipeline and for good reason. I also suspect that there will be significant work in multithreading. As per Intel usual, cache architecture will rock.

 

[phynicle]

dual core is a good guess i rekon

 

[Saem]

Dual core is a bad idea, actually. It just seems like too much overhead. Intel is pretty big on keeping die sizes down for good yields. Barring Willie which was a blip on the radar since they were a little desperate.

I suspect Alpha-esque SMT, though one should realize it'll be hosed enough so Itanium doesn't get spanked. Of course, I'm being a bit pesimistic with Itanium since there are many low-hanging fruit on the Itanium tree interms of performance.

 

[pascal]

My hope is a conservativy RISC like very high IPC architecture.

 

[Saem]

IPC and x86 don't mix. The Athlon is already pushing the barriers of ILP in x86 code. I believe in most code, 3 instructions per clock is about the limit for x86. This is why multithreading is necessary and faster clock rates are a better approach, than wider machines.

BTW, I thought it was a widely held view/known fact that brianaics tend to miss their mark.

 

[psurge]

I hope they implement a 64bit RISC style ISA with plenty of registers (say 32 integer, 64 FP, with vector instructions).

Then they have separate decoders for x86 and the new ISA, which both fill the trace cache. Yes I know this is very unlikely, (is it even possible?)

Serge

 

[Saem]

Well if one made a new ISA with lots of registers and all that fun stuff you could make a core that runs that. Perhaps, then you could make a decoding block which would bridge x86 to the new ISA, this is basically what's done now. Except the underlying RISC ISA used has a lot of x86 traits.

What you're suggesting is basically a hardware transmeta scheme. Convert the x86 to some other ISA and execute that. This is demonstrated in Itanium processors. The problem is there is no OoOE.

Personally, I'd like to see transmeta put out a faster multithreading core which can excute program and code morphing code at once and have things like trace cache to speed up decoding rather than doing it all in software.