Intel Prescott Already Has 64-bit Extensions

<A HREF="http://www.xbitlabs.com/news/cpu/display/20031027151409.html" target="_new">http://www.xbitlabs.com/news/cpu/display/20031027151409.html</A>

----------------
<b><A HREF="http://geocities.com/spitfire_x86" target="_new">My Website</A></b>

<b><A HREF="http://geocities.com/spitfire_x86/myrig.html" target="_new">My Rig & 3DMark score</A></b>

:\

Shocking if you've been ignoring all of the rumors for the past year or more. Nothing new at all if you haven't been ignoring them.

Personally I still think that these extensions are just an emulation of IA64. The P4 probably has enough out of order execution elements to handle emulating IA64's EPIC architecture if Intel just made the logic units 64-bit instead of 32-bit. (Much like AMD did to turn a K7 into a K8.)

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

Exactly. That would be the idea. Think about how many more software developers would be writing programs for IA64 that way.

Everyone thinks that if Intel releases a hybrid 32/64-bit P4 that it will weaken their Itanium market. But if that hybrid uses IA64 as its 64-bit extensions and that hybrid doesn't outperform an Itanium in FP (and what P4 could) then it'll actually strengthen the Itanium market by giving more incentive to port software to it without actually replacing the purpose of an Itanium.

It's a bit nuts considering the architectural differences between x86 and EPIC, but I think that with the extra caches, extended tables, etc. Scotty might just be able to pull it off. And if not Scotty...

So my wild conspiracy theory is that Yamhill hasn't come out yet not because Intel doesn't want to release a hybrid processor, but because Intel doesn't want to release a <i>weak</i> hybrid processor. So Intel has just been waiting for a P4 with enough on-die storage and out of order execution excellence to handle emulating EPIC.

Yeah. I know. I'm crazy.

That's the beauty of microcode. The P4 doesn't even directly execute x86 anymore. It's all translated into micro ops. So if IA64 was also translated into the same micro ops (with 64-bit extensions built into the micro-ops obviously) then the 'emulation' is really just a translation layer in the exact same way that x86 is already handled by the P4.

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

I'm willing to bet it's a dumbed down ia64. Eventually 32bit is going to die, especially once 64bit becomes prevelent. Once we get far enough out that there is no functional need for 32 bit backwards compatibility they will remove it... and its only logical to reuse what you already have as far as possible with itanium. So it will be compatible with ia64... I wont go quite as far as slvr, but I will say intel won't waste the opportunity to get more software for itanium (or more easily ported at worst case.)

Shadus

What is the scope of a subset?The subset means the processor is capable of some 64 bit instructions?Then why not software cannot support it.For all the 64 bit instructions which doesnt have native support in the processor the emulation will take care.So as the processor subset is essential instructions it will run with decent speed too

> The P4 itself is radically different from a traditional
>pure x86.

Not really. its just a highly tweaked/optimized x86 core.

>AMD made their additions and extensions to the K7 to make a
>K8 with an almost identical footprint

x86 versus x86-64 (AMD64) is an order of magnitude simpler than x86 -> IA64. I wouldnt know where to begin really.

> The architecture is already designed for extreme OoOE

Surely you realize the whole concept of EPIC is to avoid OoE ?

>Cool. Care to sign that in blood? There's always a good
>market for souls.

No, but I'm willing to take 100-1 bets. If there is a Paypal thing that allows this, I'm on.
>. Scotty is extending that capability even further by
>increasing several caches and tables
>This supposed 'minor core revision' is just several steps
>closer to everything that a P4 would need to emulate EPIC
>through a microcode translation layer well enough to not be >laughed at.

Caches and tables ? WTF are you talking about ? "Scotty" is to the P4C what Northwood is to Willamette. What you are suggesting here, is about as impossible as that scotty is able to execute Power4 binaries at speeds similar to IBM's implementations.

>Serously though, I'm not saying I have some insider info
>and I know it will be. I'm just saying that from both a
>technical and marketing standpoint it's not only possible
>but would be the most beneficial route to take.

Its technically just impossible. If it where, why do you think they designed the Itanium the way they did ? Why not create a P4 derivate to handle IA64 ?

100-1 bet, really, I'm on.

= The views stated herein are my personal views, and not necessarily the views of my wife. =

What about a dual CPU mobo with 1 Itanium and 1 P4? ***evil grin***

I'm just dreaming a bit... But I don't really want to risk my soul or anything betting on what Intel has or hasn't implemented... I just hope it gets to us, the end users, quickly, runs fast as hell, and isn't overly expensive... (OK, that would be paradise, I know...)

<font color=red><b>M</b></font color=red>ephistopheles

I was kinda thinking of a system in which you could complement each other's weaknesses... if they're running different apps, then that would be hard...

<font color=red><b>M</b></font color=red>ephistopheles

around 2005

Unified FSB socket for IA32 and IA-64.

I dont like french test

Are you kidding me? Only someone who doesn't have a clue what they're talking about could say something so silly.

I never said that it wasn't. For AMD to do it with their implementation of x86 would be damned difficult. The P4 however is an order of magnitude closer to IA64 than pure x86 is.

And even then, only said that it <i>could</i> be possible and that <i>if</i> it is possible then it's likely only become feasable thanks to the increased room provided by 0.09 micron etching. It might not even be feasable until something even smaller. I don't know. But I'd bet everything that I own that at least one engineer at Intel has given it thought.

Surely you realize that the whole concept of EPIC is <b>not</b> to avoid it at all but to instead take it to the next level. EPIC processes the logic for both sides of a possibility so that once the answer is known it's already part of the way past that comparison. It then just tosses the computations made for the unused side of the path aside. If processing both sides of a comparison before the result of the comparison is even known isn't executing code out of order then nothing is.

I don't wager for money. That's too mundane to be interesting to me.

You obviously have no idea what you're talking about. Go do some research and come back when you have a clue.

No, what I am suggesting here is that Scotty or Tejas might be able to execute IA64 binaries at speeds that are slower than an Itanium but roughly equivalent to x86. What's so ludicrous about that? If a P4 had the necessary registers, caches, tables, and all of the units had the required bit-size then why couldn't a P4 with its much faster clock be capable of emulating IA64 code to speeds that are roughly equivalent to x86-64 code running on an Opteron? If you wish to debate this any further then you will have to explain to me just exactly why that is technically impossible.

So far I'm giving technical reasons. So far you're giving generalized blanket statements. Step up or give up.

I've already said. Because until now the etching process hasn't allowed for enough to be fit into the die for a P4 to handle it. I shouldn't have to be repeating myself here. You really suck at this debating thing.

And I never even said that Scotty definately would be able to handle it. It could be Tejas. It could even be after that. But the technical direction that the P4 is going in is definately that road, so it would be silly for Intel to not at some point bridge the remaining gaps between the P4 and the Itanium into one new core if for no other reason than to compete with a 32/64-bit hybrid from AMD if the concept of a hybrid proves to be a valuable new market.

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

Yes it would be much easier to just put a P4 core and an Itanium core both into the same die and whenever the Itanium recieves 32-bit x86 commands to just route them to the P4 part of the core for computation instead of using Itanium's own slow x86 emulation.

The flaw however is that the end product will just be a multi-cored die that's even larger than a single Itanium with only one Itanium in it. It won't compete with multi-cored dual Itaniums and it'll be a shite load more expensive than any Xeon. It couldn't even hope to compete in the same market as Opteron for price reasons alone and thus would be an almost completely useless concept.

So easy does not necessarily translate into effective.

Much harder but also much more effective would be for Intel to do what I've said. Production costs would be equivalent to Xeons. Performance wouldn't be against an Itanium, but against an Opteron. The Itanium market would remain untouched and Intel would have a product capable of competing in the same market as an Opteron if not an Athlon64.

Exactly. Which is why I keep saying that it doesn't even need to be in Scotty. It could be in Tejas. It could even be later than that. Intel still has plenty of time to work out how to make it possible before they have to release <i>any</i> type of hybrid to compete with AMD's hybrids. And the need to work it out still could be exactly why Intel <i>isn't</i> trying to compete with AMD's hybrids right this very second.

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

I think you're thinking of speculative execution, not OoOE. Speculative execution is when a branch is taken even though the result isn't known. IA-64 attempts to solve this problem by processing both branches and discarding the one that was incorrect.
OoOE is when you're executing multiple instructions that have a specific order and due to one reason or another, one of these instructions can't be executed. You can then execute an instruction that comes after that one while putting this one on "hold" and executing it later.

The whole point of IA-64 and EPIC in general is to make OoOE unneccessary. Compilers will analyze code beforehand and attempt to order it in such a way so that there will be no instances in which instructions are halted. This saves the processor from having to analyze instructions on-the-fly, costing die space, transistor cost, power, heat, all of which could be used for other things such as a wider execution engine.

Sure, you could put OoOE on an IA-64 chip.....but the whole point of IA-64 was to make it unneccessary. The actual core of Itanium and Itanium 2, even including the dedicated x86 processor that's latched onto there, is still smaller than the core of the P4 or Athlon.

With the 150+ million transistor budget and constantly growing for future chips (including Teja), it could be very feasible that the chip will have 2 front-ends. One to decode IA-64 instructions and another to decode x86 instructions.
As for how the instructions are processed in the back-end. Again, there's no reason you can't put OoOE logic on an IA-64 chip. It simply isn't neccessary and, in Intel's eye, just wastes die space. However, if you were to fuse an x86 processor with an IA-64 processor, you'd need that OoOE logic there anyway for processing x86 instructions, so why not have it there to give poorly written/compiled IA-64 code that extra edge? They could always improve their compilers and later on take away the x86 component in favor of software emulation. And in the mean time, they'll give programmers time to adjust and transistion to EPIC concepts.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.

Silver, pardon the interruption, but...

I'm pretty paranoid when I say that this is almost as if you two secretly talked and decided to spoof what me and BB did, by putting BB as me and you as him!
Seriously, I know this is crazy, but damn, the situation is almost too accurate to be coincidental, especially that it was a few days ago that this fight between me and BB stopped.
That first quote by him is especially scary, as this is what I said at some point.


Tell me I'm nuts.


One more thing, what is microcode exactly? Why is it another method aside from lasering, to configure a chip's functions as you two were debating for the Opteron's active HT links?

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new"><font color=blue><b>This just in, over 56 no-lifers have their pics up on THGC's Photo Album! </b></font color=blue></A> <P ID="edit"><FONT SIZE=-1><EM>Edited by Eden on 10/30/03 03:16 PM.</EM></FONT></P>

>You sure about that? I'd love to see your source of
>information. From what I can find on a pure 0.13 micron
>comparison basis the Itanium2 has a die size of 374mm2
>while the P4 has a die size of 146mm2 and the TBredB has a
>die size of 84mm2.

Have a look here:<A HREF="http://www.scd.ucar.edu/dir/CAS2K3/CAS2K3 Presentations/Mon/loft.ppt" target="_new">http://www.scd.ucar.edu/dir/CAS2K3/CAS2K3 Presentations/Mon/loft.ppt</A>Look at the last slides. Too lazy and not enough time to do the math, but its probably correct that the Itanium has a smaller core than the P4 or Athlon on the same process node.

> (think BIOS but for the CPU instead of the mobo)

This is a pretty simple but accurate explication of what microcode is. But how exactly do you think this would help achieving:

>You could easily have one chip support two different front
>ends. In a way Itanium already does.

It doesnt really, its not related. Supporting two radically different instruction sets is anything but easy. I'm not saying it can't be done, and if anyone can do it, its probably intel, but there is no way in hell this going to happen with prescott, and I seriously doubt tejas will support IA64.

>It would not take much effort at all to turn the P4's OoOE
>hardware into speculative execution hardware,

*cough*

>especially
>when the P4's clock speed can be double that of an Itanium

And what makes you think this IA64-P4 hybird would also achieve double the clockspeed of an Itanium ? You think its trivial to have 128 registers and running the core at those speeds ? Designing a core to achieve such high clockspeeds is an incredibly challenging job, and requires an extremely good balance of all the components. You can't just slap on a VLIW decoder, increase your register count by a factor 16x, double their size, change just about every core component as well and expect your design to reach anywhere over 100 Mhz without a from the ground up redesign.

Itanium was designed from the ground up; if it was easy to support two different ISA's on one chip, both running full speed, Itanium would have been that chip. Even intel couldnt manage that with a chip that has almost limitless die estate and power envelope. There are even lots of rumours that the x86 decoder is holding back clock scaling of the Itanium, and will therefore by removed in future versions. If they couldn't do it with Itanium (btw, where Transmeta could, with a VLIW core running x86 at decent speeds), I really don't see how they will do it with prescott or tejas.

= The views stated herein are my personal views, and not necessarily the views of my wife. =

Normally I'm not THAT good looking in Intel PDFs (goddamn weak search engine IMO), but I found it: 8 stages, Page 191 of this article <A HREF="http://ftp://download.intel.com/design/Itanium2/manuals/25111002.pdf" target="_new">http://ftp://download.intel.com/design/Itanium2/manuals/25111002.pdf</A>
Interesting still, it limits it even more to clock speed compared to Athlons, yet 1.5GHZ on 0.13m is doable.

EDIT: 10 stages for FPU. Although if we measured scalability by that, then the Athlon's 13-15 stages for FPU is even farther than the Itanium. (I don't remember the exact FP figures)
--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new"><font color=blue><b>This just in, over 56 no-lifers have their pics up on THGC's Photo Album! </b></font color=blue></A> <P ID="edit"><FONT SIZE=-1><EM>Edited by Eden on 10/30/03 08:50 PM.</EM></FONT></P>

Well, think about HT, it was there all along, just never properly implemented. They needed the HT P4 versions to get it to work. Think also of how many own WinXP at P4 launch in 2000. Practically no one really. HT on Win2K is death of OS literally.

64-bit without no support is awkward, so to me it seems highly unlikely there are any extensions hidden in your CPU.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new"><font color=blue><b>This just in, over 56 no-lifers have their pics up on THGC's Photo Album! </b></font color=blue></A>

Juin just one question: When you say "bolt", do you mean "both"?
If so, you should try to say the latter, as I've always thought you refered to a company called Bolt and it's not a very close word to "both".

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new"><font color=blue><b>This just in, over 56 no-lifers have their pics up on THGC's Photo Album! </b></font color=blue></A>

About as trivial as the 128 physical registers on the P4 running at 3.2 GHz is......You only see 8 in the ISA but there's 128 physical ones in there for register renaming, etc.

I dont get your point

I dont like french test

A 1.5GHZ system is more than adequate for the average work. It's decent enough to transition your software, no?
Also, going from P2 300 performance 32-bit to some 1.5GHZ equivalent is quite good, and if Intel improves on it, it can only get better as a boon for transitioning.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new"><font color=blue><b>This just in, over 56 no-lifers have their pics up on THGC's Photo Album! </b></font color=blue></A>

that was my point if itanium = a P4 core of the same cache size and FSB a 2GHZ itanium would performe like a XEON 2ghz 400 fsb and 6MB of L3 cache that good performance for office use as the main apps and os will run native mode and X86 emulation is good for 99% od all apps on the market exception to game but game need bandwith not cpu power.

By clearing the IA-32 emulation wich sit right at a very need place between the cache and excution units/front-end.

I dont like french test

(This reply is general and not to anyone in particular)

Now, as slvr said, it is not too hard really to emulate IA-64 on x86, but what's the point of that? Tell me. Compare the performance of a 3.2Ghz P4C, to that of a 1.5Ghz Madison, and Madison beats the P4 in every category, except Integer performance. Madison more than makes up for it with it's FP performance, which crushes everything, from K8's to P4's, all the way to Power 4's and Alphas. It just would not make sense to emulate IA-64 in a P4. Intel is rather doing the opposite; they are using the FX32! concept to emulate ( in software) X86 on the Itanium. The Alpha engineers are working at this over at Intel, and as many of you already know, have gotten the emulation to 1.5Ghz Gallatin Xeon speeds. They are improving this everyday. With this kind of performance, the concept of using x86 to emulate IA-64 is rather absurd. Intel, at most, would make a hybrid with x86 and IA-64 front-ends. This would be mostly an IA-64 chip, with x86 decoders.

The current x86 core, which is basically a slapped-on Pentium core, sits on the Itanium between the cache and the front-end, and Intel is eager to get rid of it. Even on the Itanium, hardware emulation of x86 is a real pain, and software emulation is just so much easier. Getting rid of it will further increase the performance of the Itanium.

Emulating in microcode simply requires too much work (is a very big hassle), and the performance of both IA-64 and x86 will suffer, as opposed to having simply 2 different front-ends.

As it stands, Intel is most likely to simply bolt on an x86 core to an IA-64 core, or just use the x86 decoders, and maybe the front-end, to make a hybrid, which would have full speed x86 processing power, as well as full speed IA-64 power.

- - -
"... In the semiconductor industry, it's good to be paranoid ..." - [Andy Grove]</font color=green>

He's just pointing out that the P4 CAN work with that much registers, whether renaming or GP registers, at such high clock speeds. (at least that's what I think)
Whether they are viewed by the programmer shouldn't make a difference nor if they are visible, I mean, the P4 still works with them at full speed, no?

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new"><font color=blue><b>This just in, over 56 no-lifers have their pics up on THGC's Photo Album! </b></font color=blue></A>

I have no idea where you see the similarity. Banias is about efficiency. It has limited parallel execution resources, but it utilizes a lot of them. Itanium 2 has *massive* parallel execution resources. 2 parallel FMAC units for crying out loud. A 6-way instruction decoder, dedicated branch units, etc.

The Power 4 has a 16-stage integer pipeline, the P4, 20. The Power 4 has a much more strict guidelines in terms of reliable data output. It also doesn't have the advantage of mass-volume yields, constant tweaking/steppings, etc. that the P4 has. And even so, it's at 1.7 GHz. The PPC970, with the same design, is set to reach 3 GHz.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.

have no idea where you see the similarity. Banias is about efficiency. It has limited parallel execution resources, but it utilizes a lot of them. Itanium 2 has *massive* parallel execution resources. 2 parallel FMAC units for crying out loud. A 6-way instruction decoder, dedicated branch units, etc

The philosophie is the same behind.Itanium was made for effenciency at higher level.P4 is made to mix ILP and TLP and it procsessing power come from it clock speed.

I dont like french test

template in I2 meet 95% of the need unlike I1 they support much more possiblity also there way to overcome that with all compiler and little thinking.FMAC will be use in almost all cpu as they are faster yes there a probleme if they come to use of division as there is no divison instruction or root square.In the case of ALU they support all instruction and able to run all at once.


Disparity and decoding are not the same there is no decoding in I2 only bundle disparity.Yes we can say that a 123 bit instruction in decode in 3 41 bit instruction but this fix and therefore that not a decoder.

I dont like french test