David Kanter (dkanter@realworldtech.com) on 4/28/12 wrote:
---------------------------
>hcl64 (mario.smarq@gmail.com) on 4/28/12 wrote:
>---------------------------
>>anonymous (no@spam.com) on 4/28/12 wrote:
>>---------------------------
>>>
>>>[...]
>>>The scheduler can dispatch up to six micro-ops every cycle, one on each
>>>port. [...]
>>
>>Ok perhaps the language was not the most appropriate.
>>
>>You are talking from the Scheduler( unified reservation station) to the exec pipes, and that is 6 alright
>>
>>I was talking from the "decoded instructions queue" *INTO* the schedulers, and
>>that is 4... at least David Kanter analyses here on SB, >indicates that.
>
>It's 4+1 for macro-fusion. Also, some of those uops can be micro-fused.
>
>DK

Curious.. how much effective is macro-fusion ? IIRC it was first developed for RISC u-arches, and by some opinions its not very good for CISC like x86.. !?.. meaning we are talking about less than 5% of the code stream in average or more ?

Isn't micro-fusing similar to AMD macro-op packing ALU+AGU ?... i mean it happens before the schedulers and its a way to mitigate pressure on the schedulers, it does not eliminate uops going to execute... that is, its a way of having more without exploding the size of schedulers and ROBs...

But yes it can augment "dramatically" the rate from the *Decoder Queue* to the *schedulers*, matter of fact to peak 8 per cycle, if those uops are dispatched(so to speak) in ensembles and not *one at a time*.. but *its confusing* the schematics around talk about 4 uops including yours Mr Kanter
http://www.realworldtech.com/page.cfm?ArticleID=RWT091810191937&p=5
.. or micro-fusing is not much effective at all, and so not considered in schematics, which doesn't seem to be the case of opinions about the tech(GH was extensively about it with ALU+AGU), or the bandwidth is exactly for 4 uops tick, no matter if "fused" or not.(micro-fusing doesn't eliminate uops contrary to what the name may imply)

4 or 8 peak ?

[ i don't think surprising the exec bandwidth(number of pipes) being larger than the frontend, because instructions can spend some clock cycles in the scheduler ( sometimes many) waiting for all dependencies to be resolved, addresses knowned and values arriving, that is why mem forwarding, renaming or re-ordering, and prediction schemes can be effective, so 4 seems more logic and balanced than 8 ]