[PATCH 1/8] Support APX GPR32 with rex2 prefix

[H.J. Lu]

On Mon, Dec 18, 2023 at 7:24 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.12.2023 11:13, Cui, Lili wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Friday, November 10, 2023 5:22 PM
> >>
> >> On 10.11.2023 10:14, Jan Beulich wrote:
> >>> On 10.11.2023 08:11, Cui, Lili wrote:
> >>>> Here are some cases:
> >>>> 0:   41 0f a8                  rex.B push %gs         ---> rex.B was not consumed, rex
> >> will print it.
> >>>> 0:   d5 01 0f a8             {rex2} push %gs      ----> Without egpr, we need to
> >> print {rex2} for it. But we can't see anything about REX2.B3 from the prefix.
> >>>> 4:   d5 19 58                  pop    %r24             ----> There is egpr, we know it uses
> >> rex2 prefix. We cannot see the information of the lower 4 bits of rex2
> >>>>
> >>>> It is not helpful to judge rex_used in rex2.
> >>>
> >>> So: REX2, like REX, is a prefix for legacy encodings. Therefore my
> >>> view is that it ought to be treated similarly to REX in the
> >>> disassembler (I'm fine to avoid the introduction of a myriad of
> >>> rex2... [no figure braces] prefixes in gas). Just like in the first
> >>> line of what you present above for the REX.B case, I'd expect the same
> >>> for REX2. E.g., taking the 2nd line from above
> >>>
> >>> 0:   d5 01 0f a8             {rex2.B3} push %gs
> >>>
> >>> An alternative, matching your intention of treating REX2 more like
> >>> EVEX, would be to (subsequently, not right away) do away with rex.B
> >>> and alike as well, and only print {rex} in that case as well. Such an
> >>> intention would then want mentioning in the description (and
> >>> eventually carrying out). The main difference between REX/REX2 and
> >>> VEX/EVEX, as I view it (and as would be speaking against this
> >>> alternative approach), is that in VEX/EVEX it is kind of normal that
> >>> certain bits are deliberately ignored (and might be set either way -
> >>> see gas'es command line options actually allowing to drive the values for
> >> some of such ignored fields).
> >>> REX/REX2, otoh, shouldn't normally specify unused bits, much like
> >>> other legacy prefixes aren't expected to be present for no reason (and
> >>> hence are explicitly printed when present).
> >>
> >> However, irrespective of what I said above, please feel free to go ahead with
> >> the simplified approach, to allow making progress. I'd like to have H.J.'s input
> >> on how to achieve overall consistency, and we can make further adjustments
> >> later on. But please make sure you actually mention this aspect in the
> >> description of the patch.
> >
> > We are going to use {rex2 0xXX}.
>
> So that's going to be {rex2} alone as equivalent to {rex} and {rex2 0xXX}
> as equivalent to rex (no braces)?
>
> Independent of that I'm of course curious how you're meaning to deal with
> - collisions with REX2 bits already set for other reasons, and
> - yet more specifically control over REX2.M.
>

This is only for disassembler to display the unused REX2 bits.

-- 
H.J.