Add AMD znver5 RMPREAD instruction

[Kalvakuntla, Umesh]

[Public]

> What is the intended way of specifying a segment override for %rcx? That operand
> being a plain register rather than a normal memory operand makes this (once again)
> odd ("once again" because we have pre-existing similar insns, e.g. MONITOR).

Apologies, this is my first patch. I tried finding the set of options needed for this. Couldn't get it right.
Can you help me add it?

> As to the opcode table entry with operands (sorry, replying to patches sent inline
> would be easier): Which of the operands does an address size override actually
> affect? %rcx holding a linear address, it would seem more likely that that's what the
> override applies to. Depending on the answer, and depending on whether
> RMPUPDATE is behaving the same in this regard, that insn may also need
> correcting in the table (alongside adjusting the entry to be added).

Yes. Will update this too.

Regards,
Umesh



> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Tuesday, November 12, 2024 7:42 PM
> To: Kalvakuntla, Umesh <Umesh.Kalvakuntla@amd.com>
> Cc: Gopalasubramanian, Ganesh <Ganesh.Gopalasubramanian@amd.com>;
> binutils@sourceware.org
> Subject: Re: Add AMD znver5 RMPREAD instruction
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 12.11.2024 13:07, Kalvakuntla, Umesh wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > Attached patch adds znver5 RMPREAD instruction.
> > Details of the instruction are available in public document
> > https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/p
> > rogrammer-references/24594.pdf
>
> gas/doc/c-i386.texi also wants updating.
>
> With you adding to ZNVER5 in i386-gen.c, the 2.42 NEWS entry then wasn't really
> correct. Imo it is thus even more so important that you actually add a fresh entry
> there as well, indicating that support is now indeed complete (assuming of course it
> really is).
>
> What is the intended way of specifying a segment override for %rcx? That operand
> being a plain register rather than a normal memory operand makes this (once again)
> odd ("once again" because we have pre-existing similar insns, e.g. MONITOR).
>
> As to the opcode table entry with operands (sorry, replying to patches sent inline
> would be easier): Which of the operands does an address size override actually
> affect? %rcx holding a linear address, it would seem more likely that that's what the
> override applies to. Depending on the answer, and depending on whether
> RMPUPDATE is behaving the same in this regard, that insn may also need
> correcting in the table (alongside adjusting the entry to be added).
>
> Jan