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

[Cui, Lili]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, October 16, 2024 3:11 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Binutils <binutils@sourceware.org>; Hu, Lin1 <lin1.hu@intel.com>; H.J. Lu
> <hjl.tools@gmail.com>
> Subject: Re: [PATCH 2/2] x86: permit non-immediate offset operands with
> direct far branches
> 
> On 16.10.2024 03:55, Cui, Lili wrote:
> >>>>>>> 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.
> 
> This use of "immediate" in the spec was brought before. I can only repeat
> that an almost identical use of "immediate" exists on the SDM's CALL insn
> page (just to give an example): "The operand can be an immediate value, a
> general-purpose register, or a memory location." Yet we treat direct CALLs as
> having displacement operands. Just to also repeat (iirc not even the 1st time):
> How insn encoding is described doesn't always match what operands the insn
> takes in assembly sources.
> 

I think this "immediate value" means that offset/displacement itself is an immediate value (not read from any other registers), we regard this immediate value as the offset/displacement operand. You can see it defined as offset/displacement in many places in the description of SDM's CALL, please do not take it out of context.

In the description of SDM's CALL:
Instruction Operand Encoding table:
Operand 1 --> offset
Operation --> tempRIP := RIP + tempDEST;


In the description of APX's JMPABS:
Description:
The 64-bit immediate operand is treated an as absolute effective address, which is subject to canonicality checks.
Operation --> RIP = tempRIP;

The current trunk clearly reflects this, and the reason we insist on rejecting your patch is because we sincerely find this difficult to accept. I kindly ask you to reconsider our suggestion.

Thanks,
Lili.