x86: AT&T syntax operand size defaults

[H.J. Lu]

On Thu, Nov 16, 2017 at 3:31 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 16.11.17 at 00:05, <hjl.tools@gmail.com> wrote:
>> On Wed, Nov 15, 2017 at 6:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 15.11.17 at 14:30, <hjl.tools@gmail.com> wrote:
>>>> On Wed, Nov 15, 2017 at 5:05 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>> On 15.11.17 at 13:46, <hjl.tools@gmail.com> wrote:
>>>>>> On Wed, Nov 15, 2017 at 2:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> So there's one first fundamental roadblock here: Quite a few FPU
>>>>>>> insns specify Dword|Qword|Unspecified. It seems rather obvious to me
>>>>>>> that this can't be right (Unspecified should only be used when only a
>>>>>>> single operand size is permitted), but even the disassembler doesn't
>>>>>>> add an 's' suffix for at least the integer form ones. Would you agree
>>>>>>> with fixing the disassembler independently of that other work?
>>>>>>>
>>>>>>
>>>>>> Will this require change assembler testcase inputs?  Will the disassmebler
>>>>>> output match the input?
>>>>>
>>>>> Well, I'd do the change in steps (in part depending on your feedback):
>>>>> As a first step I'd like to fix the disassembler output, perhaps without
>>>>> touching the input files (but bringing them out of sync, yet as there
>>>>> are numerous examples where input and output don't fully match, I
>>>>
>>>> By "match", I mean I can tell assembler output is correct.  It is OK that
>>>> the disassembler output isn't exactly the same assembler input.
>>>
>>> Oh, perhaps you've assigned stronger meaning to "exact" that I
>>> had meant: Of course there can be cosmetic differences. What I
>>> mean here (and what is the case elsewhere) are differences in
>>> suffix between input and disassembler output.
>>>
>>>>> would have thought this is no problem; let me know your preference).
>>>>> As a second step I'd like to change all test cases (inputs, and where
>>>>> necessary outputs) where we wrongly rely on ambiguous behavior.
>>>>
>>>> Sure.
>>>>
>>>>> The 3rd and final step then would be to actually change the assembler.
>>>>>
>>>>> As you want me to have checked a Linux build against a such
>>>>> changed assembler (and I'd imply a gcc bootstrap would be helpful to
>>>>> do too, plus perhaps also using that resulting gcc for said Linux build),
>>>>> this last step will take me a while. I would nevertheless hope that you
>>>>> could agree with doing the first two steps earlier.
>>>>
>>>> Such assembler change must pass Linux kernel build for both i386 and x86-64
>>>> as well as GCC and glibc build/test.
>>>
>>> As said, I did imply gcc and Linux. I don't think I'm in the position to
>>> try glibc - I've never built that, and I wasn't planning to. You also
>>> didn't make this a requirement back when I had first started this
>>> thread.
>>
>> You check kernel and GCC.  I will check glibc after your patch is merged.
>
> Thanks for the offer. However, to get started at all, I first need an
> opinion either way on the floating point insn aspect mentioned
> earlier (and kept in context at the very top above).
>

Please remind me again what options we have for FPU instructions.


-- 
H.J.