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

[Hu, Lin1]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, October 10, 2024 4:31 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 10.10.2024 09:51, Hu, Lin1 wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Thursday, October 10, 2024 3:10 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 10.10.2024 04:41, Hu, Lin1 wrote:
> >>> And I think 'movabs moffs64, %rax' and 'movabs imm64, %rax' are two
> >> different instructions, they have different opcode.
> >>
> >> Yes.
> >>
> >>> According to spec, jmpabs is closer to 'movabs imm64, %rax', because
> >>> jmpabs
> >> only accept imm64.
> >>
> >> The "because" here is unjustified, at least as long as you can't
> >> point me at where this is being said. Hence the "why" on the first part of the
> sentence remains open.
> >>
> >
> > On page 233 of Document (https://cdrdv2.intel.com/v1/dl/getContent/784266)
> it is written "The 64-bit immediate operand is treated an as absolute effective
> address, which is subject to canonicality checks."
> >
> >>
> >> All the spec says is that there is a 64-bit field as the only
> >> operand. It says nothing on this being an immediate or a
> >> displacement. In fact, as
> >> (indirectly) pointed out before, the boundary between the two is
> >> actually fuzzy in the SDM; the strong distinction between them is something
> assemblers invented.
> >
> > In the document I posted above, I think it's kind of explicitly written clearly.
> 
> Then please look at this text taken from the CALL insn page of the SDM:
> 
> "The operand can be an immediate value, a general-purpose register, or a
> memory location."
> 
> Since neither "general-purpose register" nor "memory location" apply to opcode
> E8, it must be an immediate. Yet in the assembler we call it a displacement.
> 

In the assembler, I think we call it displacement, because its address is displacement to relative to next instruction rather than the operand being an immediate.

Looking at the encoding, it may be that their operands are encoded on IMMEDIATE, I don't think that means that they are generalizable in the form of their use, the two operands express completely different meanings. It doesn't make sense to me to use the past displacement to define the present abstract address.

>
> >>> If jmpabs want to accept moffs64, it should use another opcode.
> >>> Even if we refer to movabs, we should recognize the possibility of
> >>> the
> >> appearance of another instruction 'jmpabs moffs64'.  Abs suffix is
> >> not a constraint.
> >>>
> >>> And in terms of usage habits, I think people feel 0x123 is a offset
> >>> rather than a
> >> absolute address.  People unfamiliar with jmpabs might see 0x123 and
> >> think the address is rip + 0x123 rather then just 0x123.
> >>
> >> Then they simply missed the point of the "abs" in the mnemonic.
> >>
> >
> > Maybe, the same thing I think has happened with movabs. I think when
> > people use "movabs moffs64, %rax", they ignore the "abs" in the
> > mnemonic, too. They determine whether it's a relative address
> 
> Relative address? It's an absolute address, not a displacement relative to
> somewhere.
> 

On the top of page 1256, "The moffs8, moffs16, moffs32, and moffs64 operands specify a simple offset relative to the segment base, where 8, 16, 32, and 64 refer to the size of the data. The address-size attribute of the instruction determines the size of the offset, either 16, 32, or 64 bits."

I think it's a displacement relative to the segment base according to the SDM.

BRs
Lin