Home Original page

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

Jan Beulich jbeulich@suse.com
Wed Oct 16 07:05:40 GMT 2024 
On 15.10.2024 21:53, H.J. Lu wrote:
> On Mon, Oct 14, 2024, 7:30 PM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> 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?
> 
> 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.

That's true for many other enhancements we've been making, including any new
ISA extension support is being added for.

Jan
More information about the Binutils mailing list