Add AMD znver5 RMPREAD instruction

[Jan Beulich]

On 29.11.2024 05:39, Kalvakuntla, Umesh wrote:
> [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?

Hmm, maybe you misunderstood: This is a question towards the spec. We first need to
know what the intentions are. Then we can sort out how to arrange for this in gas
(and further consider whether to permit improved syntax also for other insns). The
answer to the spec question may very well be "do it like it was always done, as we
don't care", but really I'd hope for a better one.

Taking Intel syntax, I'd expect ordinary memory operands to be spelled like such,
even if they require a fixed register:

	rmpread	[rcx], rax

And then similarly for the older RMPUPDATE:

	rmpupdate rax, [rcx]

And alike for AT&T syntax:

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

Then adding segment overrides becomes simple, as they would naturally go on the
memory operands. Yet there may of course be reasons why this syntax wasn't used
originally, and hence why it shouldn't be used either for RMPREAD.

Following the spec to the letter would mean no operands at all to these and
several other insns. That's undesirable, too, as it makes it harder to spell out
(assembly) or distinguish (disassembly) forms with and without overrides (segment
and/or address). Hence why _some_ form of operands was introduced in gas, short
of the specs (Intel's included) making this explicit.

I'd like to further note that I question the correctness of the RMPUPDATE handling
in gas (and then likely also in objdump; didn't check yet): I just can't see how
an address size override could affect %rax (holding a physical address), rather
than %rcx (holding an effective address). This wants confirming, and the mistake
(if there is one) not repeating here, but rather correcting for RMPUPDATE then,
too. If otoh that _is_ how hardware behaves, then it surely warrants a comment
next to the respective RMPUPDATE entry in our opcode table. (I notice I didn't
pay close enough attention to this also when originally reviewing the SNP patch,
and when then fixing things in c0e54661f755.)

Jan