Home Original page

[PATCH 2/2] x86/APX: support JMPABS also in assembler

Jan Beulich jbeulich@suse.com
Wed Oct 9 11:39:53 GMT 2024 
On 09.10.2024 12:51, H.J. Lu wrote:
> On Wed, Oct 9, 2024, 6:16 PM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> On 09.10.2024 11:52, H.J. Lu wrote:
>>> On Wed, Oct 9, 2024 at 4:48 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 09.10.2024 10:41, Hu, Lin1 wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Wednesday, October 9, 2024 4:28 PM
>>>>>> To: Hu, Lin1 <lin1.hu@intel.com>
>>>>>> Cc: Binutils <binutils@sourceware.org>; Cui, Lili <lili.cui@intel.com>;
>> H.J. Lu
>>>>>> <hjl.tools@gmail.com>
>>>>>> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
>>>>>>
>>>>>> On 09.10.2024 09:45, Hu, Lin1 wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>>>> Sent: Wednesday, October 9, 2024 3:42 PM
>>>>>>>>
>>>>>>>> On 09.10.2024 09:33, H.J. Lu wrote:
>>>>>>>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be
>> "jmp64
>>>>>> foo"
>>>>>>>>> if there is one.
>>>>>>>>
>>>>>>>> As to the latter - of course. But how does the latter constrain the
>>>>>>>> former in any way? I'm sorry to say that, but you make statements
>>>>>>>> without actually providing explanations. Yet it's the explanation
>>>>>>>> that's crucial here if you want to convince me of (or at least make
>>>>>>>> me understand) your view of the situation. I for one did explain why
>>>>>>>> I think we'd better support both forms (and you demonstrated that
>> I'm
>>>>>>>> right there by the two contradicting initial replies of yours).
>>>>>>>
>>>>>>> From doc and the results of our previous discussions with relevant
>> colleagues,
>>>>>> the operand should be a 64-bit immediate operand about instruction
>> encoding.
>>>>>> Maybe they have the same bytecode, but I don't think we should
>> confuse them,
>>>>>> we should make it clear to anyone who sees this instruction that it's
>> an
>>>>>> immediate operand.
>>>>>>
>>>>>> Same question as to H.J.: Why? What's wrong with it not requiring the
>> $ in AT&T
>>>>>> syntax and, worse, the "offset" in Intel syntax when a symbol is
>> referenced?
>>>>>> People wanting to use the immediate form can very well do so.
>>>>>> People preferring the displacement form would better not be forced to
>> use a
>>>>>> form they're not comfortable with. Unless - as expressed before -
>> there actually
>>>>>> is a reason to enforce such a constraint. Yet so far I've not seen
>> any such reason
>>>>>> being spelled out.
>>>>>
>>>>> If we have another instruction like "jmpabs foo" in the future, but
>> its opcode isn't A1, how does binutils distinguish between them?
>>>>
>>>> I discussed this in an earlier reply. If you have concerns there,
>> please describe
>>>> what that supposed insn form would do. It can't be a relative direct
>> jump (or else
>>>> the "abs" in the mnemonic was wrong), and if it was a relative indirect
>> one, it'll
>>>> require a * prefix on its operand to be consistent with other indirect
>> branches.
>>>> Plus, as explained earlier, that would then be exactly the same as "jmp
>> *foo", so
>>>> there's hardly any reason such a redundant encoding would ever be added.
>>>>
>>>
>>> imm64 in jmpabs is the same type as imm64 in movabs.  imm64 should be
>>> expressed as "$symbol" in AT&T syntax.
>>
>> Which of the two MOVABS forms do you mean? The A0/A1 encoding
> 
> The one with the imm64 entry.

Come on, don't have me ask for every detail. Why would it be that one to
compare with and not ...

> doesn't use
>> imm64 but moffs, and clearly that's closer to JMPABS (same opcode,
>> different just by REX/REX2)

... this other one?

Just to repeat - it doesn't help move the discussion forward if you merely
make statements, without backing them up with respective reasoning. I
can't help getting the impression that you simply can't justify what you
want, and it's instead merely a subjective choice of yours.

>> than the B8...BF encodings.

Jan
More information about the Binutils mailing list