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.
Technology Stocks : Advanced Micro Devices - Moderated (AMD)
AMD 215.32-0.2%Dec 30 3:59 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Petz who wrote (62315)11/6/2001 2:13:01 PM
From: Joe NYCRead Replies (2) of 275872
 
Petz,

Suppose that the decode stages are the bottleneck as far as the clock speed is concerned. It is not illogical to put a buffer / cache inbetween (Trace cache). Otherwise, (assuming half speed decode) you would have P4 with much slower clock speed. 100% of the time, as opposed to, say 15 or 20% of the time, when the code is not running from trace cache.

It is theoretically possible to increase the size of trace cache, or add another decoder in parellel to increase throughput.

Looking at Hammer slides (and I am not looking at them, since I don;t have them handy) I seem to recall that somehow they started to measure the time of the stages after the decode. Could this be a hint that AMD is also cutting down the speed of the decode stage logic? If I recall correctly, Hammer has 3 sets of decode pipelines. It seemed almost like an overkill, but if they run at half speed, they can only decode 1.5 instructions per clock combined.

Joe

PS: I would like to see someone (AMD?) examine P4, and somehow "leak" the information about the speed of the decoder, if it agrees with what Kap said.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext