CFCMOVcc with 16-bit register destination

[Beulich__Jan]

From present documentation one can only assume that these follow the pattern used elsewhere: The 3-operand form (then also for the CMOVcc one) clears the upper 48 bits, while the 2-operand forms leave them unaltered. Other (useful) possibilities certainly exits, in particular that of the 2-operand forms also clearing the upper bits. It would be nice if this could be made explicit in the doc.

[Ching-Tsun_Chou · Accepted solution]

“CFCMOVcc reg, r/m” always zeros out reg[64:OSIZE] for all OSIZE.  This is explicitly stated in multiple places in the APX spec:

Sec.3.1.2.4, Merge vs Zero-Upper at the Destination Register:

CFCMOVcc (Conditionally Faulting CMOVcc) of the forms “CFCMOVcc reg, reg1” and “CFCMOVcc reg, mem” (see Section 3.1.3.2.2) follow the same rules as if reg were an NDD (namely, its bits [64:OSIZE] are zeroed). Additionally, if the condition code evaluate to false, reg is completely zeroed.

3.1.3.2.2 CMOVcc Extensions

If the destination of any of the four forms of CMOVcc and CFCMOVcc in Table 3.5 is a register, we require that the upper bits [63:OSIZE] of the destination register be zeroed whenever OSIZE < 64b.

The APX spec can be found here:

https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html

[Beulich__Jan]

Hmm, you're right, there is text there. Just that most of it is not where one would look for it - on the instruction pages themselves. The much shorter part that is (also) there imo suffers from some wording issues. In particular "..., we require
that the upper bits [63:osize] of the destination register be zeroed whenever osize < 64b" is pretty odd. "We require" reads more like an expectation on source operands than a description of what an insn does. I kind of assume though that the latest when this is eventually integrated into the SDM, issues like this will be sorted.