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

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

[Jan Beulich]

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").
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?

Thanks, Jan

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

[Cui, Lili]

> -----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

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

[Jan Beulich]

On 26.01.2025 04:27, Cui, Lili wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, January 24, 2025 7:29 PM
>>
>> 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.

If REX2 may be present on insns without any explicit register/memory operands,
but outside of the designated "forbidden" rows, some very funny situations
arise. For example, while INS and OUTS may then be REX2-prefixed, all of the
other string insns (not counting XLAT as such) can't be.

For context: When doing further libbfd side work for GOTPCREL relaxation, I
ended up quite puzzled that PUSH <imm>, when (kind of by accident) encoded with
a REX2 prefix, actually disassembled okay. If it's indeed permitted, it would
actually simplify things there (even if just a little).

Jan

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

[Cui, Lili]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, January 27, 2025 4:42 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Binutils <binutils@sourceware.org>; Jiang, Haochen
> <haochen.jiang@intel.com>; H.J. Lu <hjl.tools@gmail.com>
> Subject: Re: x86/APX: clarification needed for where REX2 may be applied
> 
> On 26.01.2025 04:27, Cui, Lili wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Friday, January 24, 2025 7:29 PM
> >>
> >> 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.
> 
> If REX2 may be present on insns without any explicit register/memory
> operands, but outside of the designated "forbidden" rows, some very funny
> situations arise. For example, while INS and OUTS may then be REX2-prefixed,
> all of the other string insns (not counting XLAT as such) can't be.
> 

Good question. The APX spec folks gave a detailed explanation. I summarize it briefly.

To reserve the "REX2" encoding space for future use. We decided to only reserve the full rows of the opcode maps in 0/1 – and not piece-wise, individual opcodes; INS/OUTS and PUSH imm are not in a row that was fully reservable (MOVSXD, IMUL, etc.), nor “half” reservable, so that row was not reserved.

> For context: When doing further libbfd side work for GOTPCREL relaxation, I
> ended up quite puzzled that PUSH <imm>, when (kind of by accident)
> encoded with a REX2 prefix, actually disassembled okay. If it's indeed
> permitted, it would actually simplify things there (even if just a little).
> 

For instructions without GPR and memory that are not disabled in the APX spec, maybe we can simplify them under options, I'm not sure if anyone would want to use rex2 for byte alignment or something?

Thanks,
Lili.

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

[Jan Beulich]

On 06.02.2025 08:01, Cui, Lili wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Monday, January 27, 2025 4:42 PM
>> To: Cui, Lili <lili.cui@intel.com>
>> Cc: Binutils <binutils@sourceware.org>; Jiang, Haochen
>> <haochen.jiang@intel.com>; H.J. Lu <hjl.tools@gmail.com>
>> Subject: Re: x86/APX: clarification needed for where REX2 may be applied
>>
>> On 26.01.2025 04:27, Cui, Lili wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Friday, January 24, 2025 7:29 PM
>>>>
>>>> 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.
>>
>> If REX2 may be present on insns without any explicit register/memory
>> operands, but outside of the designated "forbidden" rows, some very funny
>> situations arise. For example, while INS and OUTS may then be REX2-prefixed,
>> all of the other string insns (not counting XLAT as such) can't be.
>>
> 
> Good question. The APX spec folks gave a detailed explanation. I summarize it briefly.
> 
> To reserve the "REX2" encoding space for future use. We decided to only reserve the full rows of the opcode maps in 0/1 – and not piece-wise, individual opcodes; INS/OUTS and PUSH imm are not in a row that was fully reservable (MOVSXD, IMUL, etc.), nor “half” reservable, so that row was not reserved.

Thanks for confirming. We're therefore doing things correctly in this regard.

>> For context: When doing further libbfd side work for GOTPCREL relaxation, I
>> ended up quite puzzled that PUSH <imm>, when (kind of by accident)
>> encoded with a REX2 prefix, actually disassembled okay. If it's indeed
>> permitted, it would actually simplify things there (even if just a little).
> 
> For instructions without GPR and memory that are not disabled in the APX spec, maybe we can simplify them under options, I'm not sure if anyone would want to use rex2 for byte alignment or something?

I fear I don't understand what your asking and/or suggesting.

Jan

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

[Cui, Lili]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, February 6, 2025 7:24 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Binutils <binutils@sourceware.org>; Jiang, Haochen
> <haochen.jiang@intel.com>; H.J. Lu <hjl.tools@gmail.com>
> Subject: Re: x86/APX: clarification needed for where REX2 may be applied
> 
> On 06.02.2025 08:01, Cui, Lili wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Monday, January 27, 2025 4:42 PM
> >> To: Cui, Lili <lili.cui@intel.com>
> >> Cc: Binutils <binutils@sourceware.org>; Jiang, Haochen
> >> <haochen.jiang@intel.com>; H.J. Lu <hjl.tools@gmail.com>
> >> Subject: Re: x86/APX: clarification needed for where REX2 may be
> >> applied
> >>
> >> On 26.01.2025 04:27, Cui, Lili wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Friday, January 24, 2025 7:29 PM
> >>>>
> >>>> 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.
> >>
> >> If REX2 may be present on insns without any explicit register/memory
> >> operands, but outside of the designated "forbidden" rows, some very
> >> funny situations arise. For example, while INS and OUTS may then be
> >> REX2-prefixed, all of the other string insns (not counting XLAT as such)
> can't be.
> >>
> >
> > Good question. The APX spec folks gave a detailed explanation. I summarize
> it briefly.
> >
> > To reserve the "REX2" encoding space for future use. We decided to only
> reserve the full rows of the opcode maps in 0/1 – and not piece-wise,
> individual opcodes; INS/OUTS and PUSH imm are not in a row that was fully
> reservable (MOVSXD, IMUL, etc.), nor “half” reservable, so that row was not
> reserved.
> 
> Thanks for confirming. We're therefore doing things correctly in this regard.
> 
> >> For context: When doing further libbfd side work for GOTPCREL
> >> relaxation, I ended up quite puzzled that PUSH <imm>, when (kind of
> >> by accident) encoded with a REX2 prefix, actually disassembled okay.
> >> If it's indeed permitted, it would actually simplify things there (even if just
> a little).
> >
> > For instructions without GPR and memory that are not disabled in the APX
> spec, maybe we can simplify them under options, I'm not sure if anyone
> would want to use rex2 for byte alignment or something?
> 
> I fear I don't understand what your asking and/or suggesting.
> 

Oh, I misunderstood what you meant earlier. I thought you wanted to optimize those redundant rex2. Just forget about it.

Lili.