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

[Jan Beulich]

On 09.10.2024 09:45, H.J. Lu wrote:
> On Wed, Oct 9, 2024 at 3:42 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 09.10.2024 09:33, H.J. Lu wrote:
>>> On Wed, Oct 9, 2024 at 3:29 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 09.10.2024 08:44, H.J. Lu wrote:
>>>>> On Wed, Oct 9, 2024 at 2:36 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 09.10.2024 08:09, H.J. Lu wrote:
>>>>>>> On Wed, Oct 9, 2024 at 2:00 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> On 08.10.2024 23:20, H.J. Lu wrote:
>>>>>>>>> On Wed, Oct 9, 2024 at 5:00 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>>>> On Tue, Oct 8, 2024 at 6:26 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>> Without this APX support isn't really complete.
>>>>>>>>>>>
>>>>>>>>>>> Since which operand type to expect in source is ambiguous, permit both
>>>>>>>>>>> immediate and displacement forms. Make sure though that in Intel syntax
>>>>>>>>>>> truly memory operand forms (<xyz> ptr and/or square-bracketing) aren't
>>>>>>>>>>> accepted. Also make sure that no illegal prefixes can be used with the
>>>>>>>>>>> insn (LOCK is being dealt with more generally elsewhere).
>>>>>>>>
>>>>>>>> (Note this paragraph of the description.)
>>>>>>>>
>>>>>>>>>>> --- a/opcodes/i386-opc.tbl
>>>>>>>>>>> +++ b/opcodes/i386-opc.tbl
>>>>>>>>>>> @@ -510,6 +510,11 @@ ljmp, 0xea, No64, JumpInterSegment|No_bS
>>>>>>>>>>>  ljmp, 0xff/5, 0, Amd64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf, { Unspecified|BaseIndex }
>>>>>>>>>>>  ljmp, 0xff/5, x64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf, { Unspecified|BaseIndex }
>>>>>>>>>>>
>>>>>>>>>>> +// In particular for AT&T syntax permit both immediate and displacement form,
>>>>>>>>>>> +// to allow people to use what they see as the better fit.
>>>>>>>>>>
>>>>>>>>>> Why do we need "jmpabs $xxx" when it is encoded the same
>>>>>>>>>> as "jmpabs xxx"?  "jmpabs xxx" is sufficient.
>>>>>>>>>
>>>>>>>>> Since disassembler displays "jmpabs $xxx", only "jmpabs $xxx" is
>>>>>>>>> needed.  It is clear that jmpabs doesn't take a displacement and
>>>>>>>>> only immediate is supported.
>>>>>>>>
>>>>>>>> Already by the two replies of yours you demonstrate that both views are
>>>>>>>> possible. And you're not the first one to be confused / have mixed
>>>>>>>> feelings.
>>>>>>>>
>>>>>>>> As indicated in a post-commit-message remark I'm also intending to
>>>>>>>> relax ljmp's and lcall's requirements. I've always viewed it as a
>>>>>>>> mistake that only immediates were supported there for the offset operand.
>>>>>>>> That's simply not consistent.
>>>>>>>>
>>>>>>>> I'm further inclined to suggest that the disassembler better display the
>>>>>>>> operand without the leading $ (in AT&T mode), at least when it's not a
>>>>>>>> purely numeric one (and in particular when it has a relocation associated
>>>>>>>> with it).
>>>>>>>
>>>>>>> This is an option.  Before we go there, how does Intel syntax support
>>>>>>> "movabs r64, imm64"?
>>>>>>
>>>>>> That's no different from MOV (because of the other MOVABS form that also
>>>>>> exists):
>>>>>>
>>>>>>         MOV     rax, <symbol>
>>>>>>         MOV     rax, [<number>]
>>>>>>         MOVABS  rax, <symbol>
>>>>>>         MOVABS  rax, [<number>]
>>>>>>
>>>>>> all mean a memory operand.
>>>>>>
>>>>>>         MOV     rax, offset <symbol>
>>>>>>         MOV     rax, <number>
>>>>>>         MOVABS  rax, offset <symbol>
>>>>>>         MOVABS  rax, <number>
>>>>>>
>>>>>> all mean an immediate operand. That is
>>>>>> - a numeric value defaults to immediate, which can be overridden by
>>>>>>   enclosing the value in square brackets,
>>>>>> - a symbolic value defaults to displacement, which can be overridden by
>>>>>>   prefixing with "offset".
>>>>>>
>>>>>> As an aside - MOVABS isn't really Intel syntax and should never have been
>>>>>> supported outside of AT&T syntax.
>>>>>>
>>>>>
>>>>> I think we should only allow the imm64 operand.  If there is a 64-bit relative
>>>>> jmp, like jmp64, in the future,  the assembly syntax will be different from
>>>>> jmpabs.
>>>>
>>>> Can you explain how this would matter? The only thing to be concerned about is
>>>> (imo) whether there might be a 2nd JMPABS form down the road, taking a memory
>>>> operand. Yet that would be no different from "JMP *symbol" that's already there,
>>>> so I don't see any potential issue here. A hypothetical JMP64 can take whatever
>>>> operands it wants.
>>>
>>> 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).
> 
> In AT&T syntax, foo is an address operand and $foo is an immediate
> operand.  Since jmpabs takes an immediate operand, only $foo is valid.

And where is it said that the operand is an immediate one? How's the doc
different in this regard from CALL / JMP / XBEGIN (with displacement)? It
says "target64", and validly so. That doesn't constrain things to immediate
or displacement. The spec doesn't even have a need to spell out how the
operand is to be expressed in assembly sources. If that was to be spelled
out, it would be in an assembly language spec, which simply doesn't exist
(in an up-to-date form, where new insns could be expected to be added as
they appear). Plus even if such a doc existed, we could _still_ decide to
support an alternative form as extension.

In assembly source it doesn't really matter whether the eventual encoding
uses a relative or absolute address. I.e.

	jmp	func
	call	func
	jmpabs	func

are quite a bit more natural / consistent than if the JMPABS was _required_
to have a $ prefixed to its operand. And again - for people preferring it
that way, we still _allow_ that form with $.

Jan