SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Politics : Formerly About Advanced Micro Devices

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Scumbria who wrote (123096)8/26/2000 9:07:46 PM
From: John Evans  Read Replies (1) of 1584868
 
RE "we don't know enough about the underlying RISC core of the P4 to make comparisons with the P3."

I was thinking that the use of a trace cache will potentially simplify things for the P4 core.

"Latency is only a problem if it introduces bubbles"

Yes, but that's what I'm worried about. With 20 instructions in flight, I think that ordering the instructions to reduce stalls will be a problem. That is why they double-pumped the ALU's. Double-pumping may hinder the speed ramp, but I think you're better qualified to answer that.

"Forwarding data is more complicated in a deeper pipeline, but is manageable"

Yes, it appears easier to manage the complexity of a longer pipe vs. the complexity of a wider issue. I've seen formulas such as C ~= (L + W^2). From the W^2, you can see that wider designs are much more difficult. Wide designs, such as the Alpha, manage the extra complexity with "clusters". With clusters, not all the forward/bypass logic is implemented; it's only implemented within clusters. For peak performance, the Alpha relies on the compiler to schedule code correctly between clusters.

Which brings me to an interesting area of speculation. Do you expect the twin cores of the sledgehammer to share functional resources? (In other words, a wider issue like the alpha.) I think it's possible. (wishfully)
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext