3 ms·
> having a floating point uOp look at more than two operands would have humungous implications for the architecture. Actually, in HSW and later all FP ops can
by Tuna-Fish 12y ago
> having a floating point uOp look at more than two operands would have humungous implications for the architecture.
Actually, in HSW and later all FP ops can have 3 register inputs, they added one to support FMA.
However, this is irrelevant. The scenario basically everyone has been talking about is exploiting a microcoded instruction. In case you are unfamiliar with the term, when the CPU frontend reads in an instruction it deems microcoded, it will stop decoding normally, and instead reads a sequence of ops from the microcode buffer that corresponds to the microcoded instruction you just executed. These ops can be anything the cpu can run -- it would be completely possible to emit a bunch of floating point compares, instructions to and their results, then take this result to the integer flags and do compare and jump on them. And for the longer microcoded ops like fp transcendentals, it would probably be possible to hide all these ops in the shadow of the normal ops, so that there would be no increase in latency.
- Symmetry 12y agoOh, I see. I hadn't recognized that fyl2x was a microcoded instruction. Looking at the page again I totally missed the footnote and he's completely right. However, for FMA I assume that they break the FMA instruction into two uOps that have to be issued back to back to the same execution unit. The changes to the reorder register renaming logic would be just too painful otherwise, especially since Intel uses a unified scheduler which also handles the integer ops. EDIT: I suppose that I tend to forget about microcoded instructions since none of the instruction sets I've worked with directly has really had them.
- Tuna-Fish 12y ago> However, for FMA I assume that they break the FMA instruction into two uOps that have to be issued back to back to the same execution unit. The changes to the reorder register renaming logic would be just too painful otherwise, especially since Intel uses a unified scheduler which also handles the integer ops. FMAs are not split, they are executed as single instructions issued in a single cycle. There were no changes to renaming or reorder logic from 3-op instructions. Since SNB, Intel has been using PRF, where the rename system is decoupled enough from the scheduler that there is no need for any changes.