[PATCH V2 3/8] Support APX GPR32 with extend evex prefix
Jan Beulich
jbeulich@suse.com
Thu Nov 9 15:39:52 GMT 2023
On 09.11.2023 15:57, Cui, Lili wrote:
>>>>> --- a/opcodes/i386-dis-evex-len.h
>>>>> +++ b/opcodes/i386-dis-evex-len.h
>>>>> @@ -62,6 +62,16 @@ static const struct dis386 evex_len_table[][3] = {
>>>>> { REG_TABLE (REG_EVEX_0F38C7_L_2) },
>>>>> },
>>>>>
>>>>> + /* EVEX_LEN_0F38F2 */
>>>>> + {
>>>>> + { "andnS", { Gdq, VexGdq, Edq }, 0 },
>>>>> + },
>>>>
>>>> There's no sign of a prefix decode step here.
>>>>
>>>
>>> The prefix decoding step is in the NF patch and its dependent patches (Part
>> II 2/6). Both are suspended currently.
>>
>> But prefix decoding is orthogonal to NF handling. Why would that step be
>> added only there?
>>
>
> In V1 NF patch, we treated {nf} as prefix, {evex} and {nf} need to be selected or empty.
>
> "XN" => print "{nf} " pseudo prefix when EVEX.NF = 1. When EVEX.NF = 0 and under certain conditions, need to print {evex}
>
> For XN:
> if (ins->vex.nf == true)
> {
> *ins->obufp++ = '{';
> *ins->obufp++ = 'n';
> *ins->obufp++ = 'f';
> *ins->obufp++ = '}';
> *ins->obufp++ = ' ';
> }
> else if (ins->evex_type == evex_from_legacy && !ins->vex.b)
> {
> *ins->obufp++ = '{';
> *ins->obufp++ = 'e';
> *ins->obufp++ = 'v';
> *ins->obufp++ = 'e';
> *ins->obufp++ = 'x';
> *ins->obufp++ = '}';
> *ins->obufp++ = ' ';
> }
>
> Now there is a high probability that nf will be treated as suffix, the specific expression is still uncertain. Maybe we should add %XE to them in this patch. make sure its output is correct.
I'm afraid there's a terminology issue here: When I say "prefix decode step"
in the context of the binutils disassembler, then that's the decoding step
involving prefix_table[]. I.e. either 66, f2, f3 (with REX2) or EVEX.pp.
Jan
More information about the Binutils
mailing list