Re: x86: AT&T syntax operand size defaults

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.


-- 
H.J.