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

[Jan Beulich]

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.

Jan