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

[Jan Beulich]

On 14.10.2024 09:25, H.J. Lu wrote:
> On Mon, Oct 14, 2024, 3:00 PM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> 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.
> 
> I believe this is encoded as an immediate operand.

We've been there in the JMPABS discussion already: Encoding and how to
treat things internally to the assembler as well as how to represent
things in source code are, to a fair degree, separate aspects.

> 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.
>>
>>>  This change serves no practical purposes for programmers.
>>
>> I'm (once again) puzzled by such statements of yours: How do you know?
> 
> Programmers write codes which work for all assemblers.
> The current assemblers will be in use for a very long time.
> This new syntax means that 0x1000 can mean an address
> or an immediate, depending on instructions.

Why that? 0x1000 (in AT&T syntax) always means an address; $0x1000
always means an immediate. My point is that for JMPABS, LCALL, and LJMP
the distinction between immediate and address is blurred. Personally I
would even go as far as saying that using immediates for the offsets
there has always been a mistake, as these are (taking your wording
above) addresses. The representation as immediates in source code was
presumably derived from this being immediates in the encoding, yet that
model wasn't consistently followed anyway - as previously expressed
(again in the JMPABS discussion) near direct CALL/JMP have immediate
operands too in their encodings, yet they're not expressed as such in
source (and validly so, imo).

> Very few codes will use it.

Which is fine for now, and may change going forward. You didn't
comment on my reasoning for making the change at all, which leaves me
with the impression that you apparently can't argue against that, yet
you're trying to make up (unrelated) reasons to argue against the
change as such (which, I'm sorry to say that, again feel like largely
subjective).

Jan