Add AMD znver5 RMPREAD instruction

[Kalvakuntla, Umesh]

[Public]

> 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

Hi Jan,
The suggestion from the spec is to update these SNP instructions the way you suggested.
Spell ordinary memory operands as they are. It is a mistake in the specification document,
and hence the previous implementations of it. The specification documents need to be
updated too (it might take time for this).

The current expectation is:
Default:
        rmpread [rcx], rax
With segment override:
        rmpread ds:[rcx], rax

The suggestion also mentions not to support the syntax without operands.

Please let me know if you have any questions, and if I can work on these updates and
send the patch.

Regards,
Umesh