[PATCH 2/2] x86/APX: support JMPABS also in assembler

[Cui, Lili]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, October 9, 2024 7:40 PM
> To: H.J. Lu <hjl.tools@gmail.com>
> Cc: Hu, Lin1 <lin1.hu@intel.com>; Binutils <binutils@sourceware.org>; Cui, Lili
> <lili.cui@intel.com>
> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in assembler
> 
> On 09.10.2024 12:51, H.J. Lu wrote:
> > On Wed, Oct 9, 2024, 6:16 PM Jan Beulich <jbeulich@suse.com> wrote:
> >
> >> On 09.10.2024 11:52, H.J. Lu wrote:
> >>> On Wed, Oct 9, 2024 at 4:48 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 09.10.2024 10:41, Hu, Lin1 wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>> Sent: Wednesday, October 9, 2024 4:28 PM
> >>>>>> To: Hu, Lin1 <lin1.hu@intel.com>
> >>>>>> Cc: Binutils <binutils@sourceware.org>; Cui, Lili
> >>>>>> <lili.cui@intel.com>;
> >> H.J. Lu
> >>>>>> <hjl.tools@gmail.com>
> >>>>>> Subject: Re: [PATCH 2/2] x86/APX: support JMPABS also in
> >>>>>> assembler
> >>>>>>
> >>>>>> On 09.10.2024 09:45, Hu, Lin1 wrote:
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>>>> Sent: Wednesday, October 9, 2024 3:42 PM
> >>>>>>>>
> >>>>>>>> On 09.10.2024 09:33, H.J. Lu wrote:
> >>>>>>>>> It should be only "jmpabs $foo", not "jmpabs foo".   jmp64 will be
> >> "jmp64
> >>>>>> foo"
> >>>>>>>>> if there is one.
> >>>>>>>>
> >>>>>>>> As to the latter - of course. But how does the latter constrain
> >>>>>>>> the former in any way? I'm sorry to say that, but you make
> >>>>>>>> statements without actually providing explanations. Yet it's
> >>>>>>>> the explanation that's crucial here if you want to convince me
> >>>>>>>> of (or at least make me understand) your view of the situation.
> >>>>>>>> I for one did explain why I think we'd better support both
> >>>>>>>> forms (and you demonstrated that
> >> I'm
> >>>>>>>> right there by the two contradicting initial replies of yours).
> >>>>>>>
> >>>>>>> From doc and the results of our previous discussions with
> >>>>>>> relevant
> >> colleagues,
> >>>>>> the operand should be a 64-bit immediate operand about
> >>>>>> instruction
> >> encoding.
> >>>>>> Maybe they have the same bytecode, but I don't think we should
> >> confuse them,
> >>>>>> we should make it clear to anyone who sees this instruction that
> >>>>>> it's
> >> an
> >>>>>> immediate operand.
> >>>>>>
> >>>>>> Same question as to H.J.: Why? What's wrong with it not requiring
> >>>>>> the
> >> $ in AT&T
> >>>>>> syntax and, worse, the "offset" in Intel syntax when a symbol is
> >> referenced?
> >>>>>> People wanting to use the immediate form can very well do so.
> >>>>>> People preferring the displacement form would better not be
> >>>>>> forced to
> >> use a
> >>>>>> form they're not comfortable with. Unless - as expressed before -
> >> there actually
> >>>>>> is a reason to enforce such a constraint. Yet so far I've not
> >>>>>> seen
> >> any such reason
> >>>>>> being spelled out.
> >>>>>
> >>>>> If we have another instruction like "jmpabs foo" in the future,
> >>>>> but
> >> its opcode isn't A1, how does binutils distinguish between them?
> >>>>
> >>>> I discussed this in an earlier reply. If you have concerns there,
> >> please describe
> >>>> what that supposed insn form would do. It can't be a relative
> >>>> direct
> >> jump (or else
> >>>> the "abs" in the mnemonic was wrong), and if it was a relative
> >>>> indirect
> >> one, it'll
> >>>> require a * prefix on its operand to be consistent with other
> >>>> indirect
> >> branches.
> >>>> Plus, as explained earlier, that would then be exactly the same as
> >>>> "jmp
> >> *foo", so
> >>>> there's hardly any reason such a redundant encoding would ever be added.
> >>>>
> >>>
> >>> imm64 in jmpabs is the same type as imm64 in movabs.  imm64 should
> >>> be expressed as "$symbol" in AT&T syntax.
> >>
> >> Which of the two MOVABS forms do you mean? The A0/A1 encoding
> >
> > The one with the imm64 entry.
> 

'jmpabs $foo' and 'jmpabs foo' are really two different things, if used as an offset, its access range is different from that of an immediate value. supporting both formats will confuse users. Is this an immediate value or an offset? But in fact, this is an immediate value. For the unknown future, we should not occupy this expression, movabs also support immediate and offset with different opcode.

movabs, 0xa0, x64, D|W|CheckOperandSize|No_sSuf, { Disp64|Unspecified|Byte|Word|Dword|Qword, Acc|Byte|Word|Dword|Qword }
movabs, 0xb8, x64, No_bSuf|No_wSuf|No_lSuf|No_sSuf, { Imm64, Reg64 }


Lili.

> Come on, don't have me ask for every detail. Why would it be that one to
> compare with and not ...
> 
> > doesn't use
> >> imm64 but moffs, and clearly that's closer to JMPABS (same opcode,
> >> different just by REX/REX2)
> 
> ... this other one?
> 
> Just to repeat - it doesn't help move the discussion forward if you merely make
> statements, without backing them up with respective reasoning. I can't help
> getting the impression that you simply can't justify what you want, and it's
> instead merely a subjective choice of yours.
> 
> >> than the B8...BF encodings.
> 
> Jan