[PATCH 2/2] x86: permit non-immediate offset operands with direct far branches

[Cui, Lili]

>>>>>> On 14.10.2024 08:50, H.J. Lu wrote:
>>>>>>> On Mon, Oct 14, 2024, 2:39 PM Jan Beulich <mailto:jbeulich@suse.com> wrote:
>>>>>>>
>>>>>>>> While Intel syntax permits such already (as can be observed by there
>>>>>>>> not being a need to prefix the respective operand with "offset"),
>>>>>>>> AT&T syntax so far strictly insists on two immediate operands.
>>>>>>>> Multiple
>>>>>>>> (successive) immediate operands are somewhat problematic anyway, as
>>>>>>>> it's never really clear what their order ought to be. While there's
>>>>>>>> no apparent way of dealing with this for ENTER, EXTRQ, and INSERTQ,
>>>>>>>> for LCALL and LJMP we can aid programmers by permitting alternative
>>>>>>>> forms, with the offset operand being a "displacement" rather than an
>>>>>>>> "immediate". The order of the two operands the doesn't matter;
>>>>>>>> they're distinguished by type.
>>>>>>>>
>>>>>>>> Mark the new templates AT&T-only; the original ones really should
>>>>>>>> have been so, too. For backwards compatibility reasons we can't
>>>>>>>> really correct that mistake ...
>>>>>>>> ---
>>>>>>>> While the proper Intel syntax operand form is sel:offset, for some
>>>>>>>> reason we also support two (comma separated) operands. The ambiguity
>>>>>>>> there is being left alone, as the sel:offset form is enough to avoid
>>>> it.
>>>>>>>>
>>>>>>>
>>>>>>> I don't think this is a good idea.  $ is used to denote an immediate
>>>>>>> operand in AT&T syntax.
>>>>>>
>>>>>> Yet as with JMPABS the question is whether this really is an immediate.
>>>>>> Just take Lili's most recent comment there: It can be looked at as a
>>>>>> displacement/offset relative to the specified segment/selector. IOW
>>>> like there I
>>>>>> think two perspectives are possible, and - as expressed by the
>>>> post-commit-
>>>>>> message remark - they're already both supported in Intel syntax.
>>>>>>
>>>>>
>>>>> I am on the same page as Hulin and H.J. I insist that offset uses "foo"
>>>> and immediate
>>>>> uses "$foo",
>>>>
>>>> And we agree here. I can only repeat that the issue here is that it is
>>>> depending on personal perspective whether one considers operands to
>>>> effectively any form of direct branch to be an "offset" or to be an
>>>> "immediate".
>>>>
>>>>> even in the special case where the base is 0, conceptually it is still
>>>> an offset (mov 0x12345678, %eax).  The current implementation and
>>>> documentation are clear and reasonable. I believe you already know the
>>>> point I want to make, so I won’t reply again.
>>>>
>>>> Right, but are you also at least trying to understand the point(s) I've
>>>> been trying to make for quite some time now? Why do we need to prescribe
>>>> to people how to write their code, when offering liberty has no negative
>>>> consequences?
>>> 
>>> Unnecessary syntax without real benefits is a negative consequence.
>>
>>So helping engineers, by disentangling the offset vs immediate situation
>>that AT&T mode effectively had forever, isn't a "real benefit" in your eyes?
>>
>Real benefit is to provide a CPU feature which can't be done by the current assembler.
>Your new syntax may confuse programmers.
>People may use it without realizing it doesn't work
>with older versions of assembler or other assemblers.

Yes, and we should follow the spec:

"JMPABS is a 64-bit only ISA extension, and acts as a near-direct branch with an absolute target.
The 64-bit immediate operand is treated an as absolute effective address, which is subject to canonicality
checks.

 tempRIP = <target64 from instruction>;
 IF tempRIP is not canonical:
 THEN #GP(0);
 ELSE
 RIP = tempRIP;"

Lili.