This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: PR gas/10637: x86 assembler failed to handle [addr] in Intel mode


On Wed, Sep 16, 2009 at 6:50 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Sep 15, 2009 at 11:48 PM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>> "H.J. Lu" <hjl.tools@gmail.com> 15.09.09 18:54 >>>
>>>Apparently, x86-64 MASM and ia32 MASM behave differently. x86-64 MASM
>>>treats [0x8000] as memory while ia32 MASM treats [0x8000] as immediate
>>>value. My questions are
>>>
>>>1. Should x86 GNU assembler treat [0x8000] the same for both 32bit and
>>>64bit?
>>>2. If yes, how should we treat [0x8000]?
>>>
>>>Personally, I think we should treat [0x8000] the same. Since we have
>>>been treating [0x8000] as memory for a long time, we should keep
>>>treating [0x8000] as memory.
>>
>> I would favor getting clarification on the difference in behavior from
>> Microsoft first. I'm sure your compiler group has contacts into Microsoft
>> that could easily and quickly get the needed information.
>>
>> Apart from that, I'm not strictly bound to which route we go, though
>> I'd favor staying compatible with masm on both 32- and 64-bits (unless
>> MS would indicate that the difference in behavior is a mistake and
>> would be fixed in masm) - perhaps with a command line option to alter
>> the behavior to be more consistent across arch-s.
>>
>
> I don't believe we should be compatible with MASM in this case even
> if MASM has done this on purpose. There are many other assemblers
> which takes Intel syntax. MASM is the only one I know which treats
> [1] differently in 32bit and 64bit modes. Both NASM and IASM always
> treat [1] as memory. Regardless what MASM people say, I consider it
> is a defect in MASM and treating [1] as memory makes more senses.
>

The response I got from MASM people is the different behaviors
in 32bit and 64bit modes in MASM were done on purpose. They
consider treating [1] in 32bit as immediate value is legacy for
historical reasons.

GNU assembler should always treat [1] as memory in both
32bit and 64bit modes.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]