[PATCH v3 10/10] x86-64: Intel64 adjustments for insns dealing with far pointers

[Jan Beulich]

On 22.01.2020 14:21, H.J. Lu wrote:
> On Mon, Jan 20, 2020 at 6:33 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 20.01.2020 14:42, H.J. Lu wrote:
>>> On Mon, Jan 20, 2020 at 2:12 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 17.01.2020 19:06, H.J. Lu wrote:
>>>>> On Fri, Jan 17, 2020 at 3:48 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 16.01.2020 21:24,  H.J. Lu  wrote:
>>>>>>> We should improve gas documentation.  The current far branches
>>>>>>> work fine.  Why bother to add new far branches without giving
>>>>>>> developer a clue how to use them?
>>>>>>
>>>>>> That's the subject of CPU documentation, not that of any assembler.
>>>>>> The current far branches "work fine" as far as they're being made
>>>>>> accessible (encodable) by gas. The 64-bit forms Intel CPUs support
>>>>>> didn't work fine at all (because one had to use hand crafted REX.W
>>>>>> prefixes), as per Andrew's bug report. There's no difference here
>>>>>> to the prior work you did to support the Intel64 / AMD64
>>>>>> differences for certain other insns - you've simply made gas
>>>>>> capable of properly encoding them in a vendor dependent manner.
>>>>>> You didn't accompany this with any documentation explaining "how
>>>>>> to use" these. If, retroactively, you think this should have been
>>>>>> accompanied by such documentation, may I ask that you add such,
>>>>>
>>>>> Yes, it is not very obvious how to use them, we should add some
>>>>> documentation.   Which one do you have in mind?
>>>>
>>>> All which currently have the Intel64 or AMD64 attribute. If all
>>>> present ones had extra documentation, then (as said) it would be
>>>> more obvious that _and_ what documentation needs/wants adding
>>>> for ones covered anew.
>>>
>>> Let's start with one first.  Please name one.
>>
>> CALL r/m (and then naturally also JMP r/m).
> 
> I used
> 
> data16 jmp foo
> 
> I think assembler should just support the common ISA.  If one wants more,
> they can use REX prefix.  Now you added a new syntax.  You should document
> it.

I'm sorry, but we're moving in circles. I've previously indicated
that I'd be fine to add documentation, as long as I know what
precisely you're after, and what part of the documentation it is
that you want to have extended (i.e. preferably where similar
information for other stuff already exists). Adding something new
has not typically been a reason to extend the documentation, when
what has got added was a natural extension of what's been there
before. Or else there would be mention of how to use various
other insns; first an foremost there would be mention of all the
64-bit extensions to pre-existing 32-bit insns back when x86-64
support was added.

Once again, give me a handle on what you want me to do, or be so
kind and supply the pieces yourself (either for me to merge into
the patch, or to commit later on top of it). Please excuse my
ignorance, but I _simply don't see_ what needs documenting here
given the documentation that is available. And I don't see
myself start from scratch something entirely new.

Jan