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

[Jan Beulich]

On 14.10.2024 12:49, H.J. Lu wrote:
> On Mon, Oct 14, 2024, 6:32 PM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> On 14.10.2024 10:13, Cui, Lili wrote:
>>>> Subject: Re: [PATCH 2/2] x86: permit non-immediate offset operands with
>> direct
>>>> far branches
>>>>
>>>> On 14.10.2024 08:50, H.J. Lu wrote:
>>>>> On Mon, Oct 14, 2024, 2:39 PM Jan Beulich <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?
Looks like a benefit can only ever be something _you_ consider beneficial.
Again - may I ask that you please try to be objective, not subjective?

Jan