Add AMD znver5 RMPREAD instruction

[Jan Beulich]

On 22.01.2025 08:29, Kalvakuntla, Umesh wrote:
> I have started with rmpupdate instruction and faced few issues.
> I have the following doubts.
> In the x86_64_table entry,
> We have tried couple of ways to get the constrained segment register. 
> Using combinations of rCX_reg and { OP_EM, OP_SEG }.
> We thought G addressing code might also be relevant in this case. But since 
> there is no implementation of OP_GM, didn't try that further. 
> Both didn't work as expected. And it is probably because of the issues in 
> Opcode table entry being problematic. 

I don't expect you can re-use anything we have there already. These insns
are special, so they'll likely need a special case handler at least for
their memory operands.

> What is the right way to specify the constrained register in Modrm operation?
> Ex: rmpupdate, 0xf20f01fe, SNP&x64, Modrm|AddrPrefixOpReg|NoSuf, { Unspecified|BaseIndex, Acc|Qword }
> In the above example, using Acc|Reg64 caused error saying Internal error in build_modrm_byte. 
> But using just Reg64, there was no error in compilation.
> Should the build_modrm_byte function be updated, or the way we are trying to describe is incorrect?

There's no true ModR/M byte in this insn; the 0xfe part of the opcode already
fully specifies what takes the place of the ModR/M byte.

rmpupdate, 0xf20f01fe, SNP&x64, AddrPrefixOpReg|NoSuf, { RegC|Unspecified, Acc|Qword }

may be getting closer to what you want (but obviously this is untested). This
will require adjustments to the AddrPrefixOpReg handling then, or maybe we
even need an entirely new insn attribute here. I would offer to take a stab,
yet then I'd first need to have a complete list of insns with their intended
new operand combinations. Aiui the two

        rmpread %rax, (%rcx)
        rmpupdate (%rcx), %rax

that you had in your earlier mail isn't the complete set.

> We have tried understanding from movq implementation using 
> Ex: movq %ss:(%rdi), %rax.
> The disassembled opcode was 36 48 8b 07. We couldn't find 0x8b07 opcode in i386-opc.tbl.

The opcode there is 8b, which you'll only find as 88 in the opcode table (the low
two bits are controlled by the W and D insn attributes). The ModR/M byte for insns
truly having one (obviously) isn't part of the opcode table entry; it is generated
by build_modrm_byte() based on the insn operands (which isn't applicable to any
insns using all dedicated registers for their operands).

Jan