Re: [PATCH 4/8] Support APX NDD

[Jan Beulich <jbeulich@suse.com>]

On 25.10.2023 17:49, Cui, Lili wrote:
>> Subject: Re: [PATCH 4/8] Support APX NDD
>>
>> 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.
>>
> 
> Sorry, my previous answer was inaccurate, EVEX.ZU will not be ignored in 32-bit and 64-bit forms.
> 
> Prior to Intel® APX, the following rules apply in 64-bit mode when an instruction’s destination is a GPR and
> OSIZE < 64b:
> 1. If OSIZE is 32b, the destination GPR gets the instruction’s result in bits [31:0] and all zeros in bits
> [63:32].
> 2. If OSIZE is 8b or 16b, the destination GPR gets the instruction’s result in bits [OSIZE-1:0] but keep its
> old value in bits [63:OSIZE].
> 
> The ZU indication described in items 2.(b) of Section 3.1.2.3.1 does not introduce an NDD. For those
> instructions, EVEX.ND=0 keeps the current x86 behavior, but EVEX.ND=1 forces the zeroing of bits
> [63:OSIZE] for any OSIZE < 64b

While described differently, that's still the same behavior as before for
OSIZE > 16b, isn't it? Which still means the EVEX.ND is effectively ignored
in those cases (and could hence as well be reserved).

>>> 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.)
>>
>  
> I will add suffix “zx” (for the Intel syntax) or “zwq” (for the AT&T syntax) to the mnemonic:
> 
> Intel syntax                                              AT&T syntax
> imulzx rax, word ptr[ rbx ], 0xab         imulzwq $0xab, (%rbx), %rax

For Intel syntax, unless you happen to know that MASM is going to go
that route, the "word ptr" is sufficient for disambiguation, and no
suffixes should be accepted (gas) or be output (objdump). For AT&T
syntax the case with a memory operand indeed requires some means to
disambiguate; as asked before, I wonder if your approach matches with
what other assemblers are going to do.

Jan