[PATCH 4/8] Support APX NDD

[Jan Beulich]

On 25.10.2023 10:10, Cui, Lili wrote:
>> On 22.10.2023 16:05, Cui, Lili wrote:
>>>>> --- /dev/null
>>>>> +++ b/gas/testsuite/gas/i386/x86-64-apx-ndd.s
>>>>> @@ -0,0 +1,156 @@
>>>>> +# Check 64bit APX NDD instructions with evex prefix encoding
>>>>> +
>>>>> +	.allow_index_reg
>>>>> +	.text
>>>>> +_start:
>>>>> +cmovge 0x90909090(%eax),%edx,%r8d
>>>>> +cmovle 0x90909090(%eax),%edx,%r8d
>>>>> +cmovg  0x90909090(%eax),%edx,%r8d
>>>>> +imul   0x90909(%eax),%edx,%r8d
>>>>> +imul   0x909(%rax,%r31,8),%rdx,%r25
>>>>
>>>> What about imul by immediate? The present spec is quite unclear there:
>>>> The insn page says {ND=ZU} and the table says 0/1 in the ND column.
>>>>
>>>
>>> We don't support it yet, I put it in RFC.
>>> ...
>>> 2. Support APX ZU   -- In progress
>>> 3. Support APX CCMP and CTEST -- In progress ...
>>>
>>> About 0/1 in the ND column, it means ZU can be 0/1.
>>>
>>> IMUL with opcodes 0x69 and 0x6B in map 0 and SETcc instructions
>>> Although these instructions do not support NDD, the EVEX.ND bit is
>>> used to control whether its destination register has its upper bits (namely,
>> bits [63:OSIZE]) zeroed when OSIZE is 8b or 16b.
>>> That is, if EVEX.ND = 1, the upper bits are always zeroed; otherwise,
>>> they keep the old values when OSIZE is 8b or 16b. For these instructions,
>> EVEX.[V4,V3,V2,V1,V0] must be all zero.
>>
>> So ZU indeed isn't just a typo there. For 32- and 64-bit forms, is EVEX.ND then
>> simply being ignored? The ZU really is meaningful only for 16-bit forms, aiui ...
>>
> 
> EVEX.ZU should be ignored for 32-bit and 64-bit forms. For imul (in spec 6.30 IMUL), EVEX.ND stands for ND or ZU.

In cases like this, where ignoring bits is kind of unexpected, the spec
would better say explicitly (on the instruction page) when a meaningless
bit is indeed ignored, rather than being reserved and causing #UD. Note
how even the text in the APX-EVEX-INT section leaves open (or at least
ambiguous, by not mentioning the case) whether SETcc with a memory
operand ignores EVEX.ND or causes #UD when the bit is set.

> I think ZU makes sense for both the 16-bit form (imul) and the 8-bit form (setcc, I'm not sure if imul supports it yet).

No, IMUL by immediate (or actually any IMUL with multiple operands) doesn't
support byte register operands. For SETcc the ZU aspect is pretty clear
and doesn't even need expressing by new syntax in (dis)assembly - you can
simply distinguish the two forms by using either 8-bit registers (no ZU)
or 32-/64-bit ones (with ZU). In principle that's possible with IMUL as
well, of course, but it may be deemed a little odd:

	imul	$17, %dx, %cx
	imul	$17, %dx, %ecx

Yet personally I'd still prefer this over adding e.g. {zu} on either the
mnemonic or the destination operand. Question (as with the way to express
{nf}) is how other assemblers are going to handle it. (Would be quite nice
if the spec could at least give more clear hints towards suggested syntax,
but that hadn't been the case already with the syntax extensions needed
for AVX512.)

Jan