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) -- Ignore unavailable to you. Want to Upgrade?


To: jcholewa who wrote (64233)11/22/2001 2:17:06 AM
From: kapkan4uRead Replies (2) | Respond to of 275872
 
<We already knew that the trace cache issued 6 ops every 2 cycles >

Hmm, I thought that you were questioning my assertion that the front-end runs at half the clock.

Message 16627961

I guess now you are saying that you always knew that the TC was running at half the clock, but still have doubts about the decoder.

<Additionally, I find myself surprised to disagree with him when he says that the decoder is only used during trace cache misses. If it wasn't, then how does the trace cache fill up in the first place?? I mean, if the decoder was inactive when the trace cache is going, then for every cycle that the trace cache hits, there would be a handful of cycles where the trace cache *must* miss because it's totally empty (because the decoder feeds the TC)!>

No, the decoder only kicks in after a TC miss. And yes everything else on the chip stops while the half clocked single decoder is replacing the evicted trace with a new one. To mitigate the horrendous performance hit on a TC miss, the new trace is being fed to the execution engine at the same time, while it is being written in the TC.

Kap