x86: AT&T syntax operand size defaults

[Jan Beulich]

>>> On 16.11.17 at 14:30, <hjl.tools@gmail.com> wrote:
> On Thu, Nov 16, 2017 at 5:16 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 16.11.17 at 13:51, <hjl.tools@gmail.com> wrote:
>>> On Thu, Nov 16, 2017 at 4:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 16.11.17 at 12:48, <hjl.tools@gmail.com> wrote:
>>>>> Please remind me again what options we have for FPU instructions.
>>>>
>>>> At present fisttp (and a few others, looks like all related to integer
>>>> operands, i.e. all fi*) default to the 's' suffix, which isn't in line with
>>>> the supposed defaulting to 'l'. The first proposed step here was to
>>>> make the disassembler properly emit 's'. Later on the assembler side,
>>>> together with the other addition of diagnostics (in the default case),
>>>> 's' as a suffix would become mandatory for warning-free operation.
>>>>
>>>> One thing you were concerned about is assembler input and
>>>> disassembler output going out of sync. There are examples of this
>>>> already, so I could see it being done either way. But if you tell me
>>>> I should change the testcase inputs as well, as that'll shrink the
>>>> size of one of the later patches.
>>>>
>>>> The other option is to retain current behavior for fi*, by special
>>>> casing them in tc-i386.c. I dislike this option, though.
>>>>
>>>
>>> FPU is complicated by:
>>>
>>> #ifndef SYSV386_COMPAT
>>> /* Set non-zero for broken, compatible instructions.  Set to zero for
>>>    non-broken opcodes at your peril.  gcc generates SystemV/386
>>>    compatible instructions.  */
>>> #define SYSV386_COMPAT 1
>>> #endif
>>> #ifndef OLDGCC_COMPAT
>>> /* Set non-zero to cater for old (<= 2.8.1) versions of gcc that could
>>>    generate nonsense fsubp, fsubrp, fdivp and fdivrp with operands
>>>    reversed.  */
>>> #define OLDGCC_COMPAT SYSV386_COMPAT
>>> #endif
>>>
>>> If you want to change it, please first investigate if they can be removed
>>> or changed.
>>
>> That affects operand order only afaict, not operand size, i.e. not
>> an issue here. In particular, no fi* mnemonics (and really no insns
>> at all which reference memory) have the OldGcc attribute. The
>> question really only is whether to require the suffix for fi* just like
>> we intend to do for other ambiguous ones, or whether to special
>> case those to retain their current behavior (which I can see as an
>> option solely because even the disassembler doesn't get this right
>> so far).
> 
> It affects the operand order as well as mnemonic for both assembler
> and disassembler.  If we touch FPU, we should fix them first.

I'm afraid I don't understand: The four affected mnemonics are
even listed in the comment in your original quote. There is no
plan to touch any of those four. Please clarify.

Jan