David Kanter (dkanter@realworldtech.com) on 1/18/11 wrote:
---------------------------
>anon (anon@anon.com) on 1/17/11 wrote:
>---------------------------
>>anonymous (no@spam.com) on 1/17/11 wrote:
>>---------------------------
>>>>>Though with the 4-1-1-1 style decoders, do each of the "1" decoders issue a simple uop or a complex uop per cycle?
>>>>
>>>>Can anyone confirm whether this speculation is true?
>>>
>>>Check Intel's optimization manual, #248966-023.
>>>
>>>Section 2.1.2.1 says this about Sandy Bridge:
>>>
>>>"There are four decoding units that decode instruction into micro-ops.
>>>The first can decode all IA-32 and Intel 64 instructions up to four micro-
>>>ops in size. The remaining three decoding units handle single-micro-op
>>>instructions. All four decoding units support the common cases of single
>>>micro-op flows including micro-fusion and macro-fusion."
>>>
>>>Section 2.2.2.4 says this about its predecessor:
>>>
>>>"All decoders support the common cases of single µop flows, including:
>>>micro-fusion, stack pointer tracking and macro-fusion. Thus, the three
>>>simple decoders are not limited to decoding single-µop instructions.
>>>Packing instructions into a 4-1-1-1 template is not necessary and not
>>>recommended."
>>
>>Yes I know this (from the manual) and acknowledged this in my post. The manual
>>also says that there is such a thing as a simple uop and a complex uop. My question
>>was do the three "1" decoders issue a simple uop per cycle or a complex uop per
>>cycle. This wasn't clear from the manual.
>
>This area is a rather confusing one. The way I tend to think about decoding is
>in terms of uops (the output of decoding). The trick is to realize that in essence,
>the definition of uops has changed generation to generation.
>
>i.e. uops from SNB, Nehalem, C2D are all somewhat different. Techniques like uop
>fusion, macro-op fusion, etc. all change the definition of uops.
>
>So the way I think about the front-end is still in terms of 4-1-1-1 templates.
>That is, the simple decoders still issue 1 uop/cycle - however, the uops are becoming
>increasingly complex and can now include two operations (e.g. mem-reg uops).
>
>Here's what the manual says (bold for emphasis):
>
>The following are examples of micro-fused micro-ops that can be handled by all decoders.
>
>• All stores to memory, including store immediate. Stores execute internally as
>two separate functions, store-address and store-data.
>
>• All instructions that combine load and computation operations (load+op), for example:
>• ADDPS XMM9, OWORD PTR [RSP+40]
>• FADD DOUBLE PTR [RDI+RSI*8]
>• XOR RAX, QWORD PTR [RBP+32]
>• All instructions of the form "load and jump," for example:
>• JMP [RDI+200]
>• RET
>• CMP and TEST with immediate operand and memory
>
>An instruction with RIP relative addressing is not micro-fused in the following cases:
>
>• An additional immediate is needed, for example:
>• CMP [RIP+400], 27
>• MOV [RIP+3000], 142
>• The instruction is a control flow instruction with an indirect target specified
>using RIP-relative addressing, for example:
>• JMP [RIP+5000000]
>
>In these cases, an instruction that can not be micro-fused will require decoder
>0 to issue two micro-ops, resulting in a slight loss of decode bandwidth.
>
>In 64-bit code, the usage of RIP Relative addressing is common for global data.
>Since there is no micro-fusion in these cases, performance may be reduced when porting
>32-bit code to 64-bit code.
>
>
>Based on what is written, it certainly sounds like any of the simple decoders can
>emit a micro-fused uop. In theory, that suggests that you could output 4 load-ops/cycle...but
>I don't know for sure. Even if it was true, it wouldn't matter, since that vastly
>exceeds the available execution resources.
>
>David

Thanks David Kanter. I had read the Sandy Bridge section of the optimization manual, where it defined simple and complex micro-ops. I think the manual says the simple uops, like from a load+op x86 instruction, are fused into complex u-ops. Though it never said whether the decoders decode a simple uop per cycle and fuse two back to back (if they can do so) for a throughput of a complex uop per two cycles, or effectively emit two simple uops per cycle and later fuse them, for a throughput of a complex uop per cycle.

If you think they can decode a complex uop per cycle, why doesn't the processor have enough execution units to keep up?

Come to think of it, maybe the fact that the processor appears bottlenecked in the execution stage suggests that Sandy Bridge emits a simple uop per cycle from the regular decoders? Otherwise it'd be a very unbalanced design.