[PATCH] Add znver3 processor

[Jan Beulich]

On 14.10.2020 23:00, Gopalasubramanian, Ganesh wrote:
> [AMD Public Use]
> 
>> Please send a proper patch generated by "git format-patch".
>> Please remove i386-init.h and i386-tbl.h from the git output.
> 
> Thank you for reviewing. PFA, the revamped patch (BuZnver3.patch).
> Changelog remains the same. 
> 
> It passes make check on x86-64. Okay to commit?
> 
> Changelog:
> 
> 2020-10-15  Ganesh Gopalasubramanian  <Ganesh.Gopalasubramanian@amd.com>
> 
> gas/
> 
>         * config/tc-i386.c (cpu_arch): Add CPU_ZNVER3_FLAGS flags.
>         (i386_align_code): Add PROCESSOR_ZNVER cases.
>         * doc/c-i386.texi: Add znver3 and snp, invlpgb and tlbsync.
>         
> gas/testsuite/
>         * gas/i386/i386.exp: Add new znver3 test cases.
>         * gas/i386/arch-14-znver3.d: New.
>         * gas/i386/arch-14.d: New.
>         * gas/i386/arch-14.s: New.
>         * gas/i386/invlpgb.d: New.
>         * gas/i386/invlpgb.s: New.
>         * gas/i386/snp.d: New.
>         * gas/i386/snp.s: New.        
>         * gas/i386/tlbsync.d: New.
>         * gas/i386/tlbsync.s: New.        
>         * gas/i386/x86-64-arch-4-znver3.d: New.
>         * gas/i386/x86-64-arch-4.d: New.
>         * gas/i386/x86-64-arch-4.s: New.
>         
> opcodes/
>         * i386-dis.c (rm_table): Add tlbsync, snp, invlpgb.
>         * i386-gen.c (cpu_flag_init): Add new CPU_INVLPGB_FLAGS, CPU_TLBSYNC_FLAGS, and CPU_SNP_FLAGS.
>         Add CPU_ZNVER3_FLAGS.
>         (cpu_flags): Add CpuINVLPGB, CpuTLBSYNC, CpuSNP.
>         * i386-opc.h: Add CpuINVLPGB, CpuTLBSYNC, CpuSNP.
>         * i386-opc.tbl: Add invlpgb, tlbsync, SNP (psmash, pvalidate, rmpupdate, rmpadjust).

Just like INVLPGA does, INVLPGB, PVALIDATE, and RMPADJUST should
allow for an optional operand to easily specify address size (i.e.
without having to resort to a non-standard prefix). Same goes
for PSMASH and RMPUPDATE when comparing with the SVM insns.

As far as the SNP insns go, aren't the templates lacking Cpu64
(and the disassembler then respective mode-dependent decoding)?

Finally your use of PREFIX_OPCODE in the disassembler tables
looks inconsistent - once decoding has gone through
prefix_table[], this attribute isn't necessary anymore (and
hence should be omitted to avoid confusing the reader).

Jan