RE: x86/APX: clarification needed for where REX2 may be applied

["Cui, Lili" <lili.cui@intel.com>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, January 24, 2025 7:29 PM
> To: Cui, Lili <lili.cui@intel.com>; Jiang, Haochen <haochen.jiang@intel.com>;
> H.J. Lu <hjl.tools@gmail.com>
> Cc: Binutils <binutils@sourceware.org>
> Subject: x86/APX: clarification needed for where REX2 may be applied
> 
> Hello,
> 
> the spec has two relevant bullet points:
> 
> – All instructions in legacy maps 0 and 1 that have explicit GPR or
>   memory operands can use the REX2 prefix to access the upper 16 GPRs
>   (namely, R16 to R31).
> 
> – Certain rows of opcodes in legacy maps 0 and 1 which do not have
>   explicit GPR or memory operands are reserved under REX2 for future
>   use.
> 
> Later those rows are enumerated. This row related statement is kind of
> redundant though with the earlier one, for no insn in those rows having any
> explicit GPR or memory operands (map 0 row A entries 0-3 are slightly special,
> but for the purpose here I take it these have displacement operands, not
> "explicit memory" ones). Yet then, with this being kind of redundant, the
> question arises how strict the first statement really is (i.e. whether it implies
> "other insns can't").

I think the early sentence emphasizes that we can use REX2 to access 16 GPRs, but it doesn't explicitly say that REX2 is disabled for instructions without GPR or memory, so the second sentence is needed to add this point. There may be a better way to express it, but I think there is no big problem with the current expression.

> Right now both gas and objdump don't follow that statement (or its
> implication, to be precise), but implement the restriction purely based on row
> numbers. The more I read the first statement though, the more it looks to me
> that what we currently do is wrong. Therefore - can this be clarified please,
> both here and in a future revision of the spec?
> 

I'm curious if you found some special instructions (without GPR or memory) that are not included in the second sentence.

I can understand what you said earlier, the two summaries have different perspectives and there may be some omissions.

Thanks,
Lili.

> Thanks, Jan