x86: AT&T syntax operand size defaults
H.J. Lu
hjl.tools@gmail.com
Thu Nov 16 14:42:00 GMT 2017
On Thu, Nov 16, 2017 at 6:40 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> 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.
>
FPU code is messy. If we want to change FPU code, we should
remove OLDGCC_COMPAT and SYSV386_COMPAT first. Or
you can keep FPU code ASIS.
--
H.J.
More information about the Binutils
mailing list