[LLVMdev] Intel vs. AT&T Assembly.

[Jeff Cohen]

Ok, less talk and more action.  I just implemented proper Microsoft 
ML/MASM support.  It probably has a few rough edges, so if anyone wants 
to try it out please do and let me know if you encounter any problems.

Note that you cannot take a bytecode file created by llvm-gcc on Unix, 
move it to Windows, translate it to Intel syntax assembler, assemble it 
with ML and expect it to work.  You'll get an object file, but it won't 
link.  It used to work, but something changed to make the C runtime 
libraries incompatible.  lli cannot run the bytecode file either for the 
same reason, nor will using CBE work anymore either.

But for those of us writing our own front ends, this isn't a problem.

Jeff Cohen wrote:
> Chris Lattner wrote:
>> On Mon, 1 May 2006, Jeff Cohen wrote:
>>> Chris Lattner wrote:
>>>> On Mon, 1 May 2006, Ralph Corderoy wrote:
>>>>> NASM might be the nicer target since it's GNU LGPL and runs on 
>>>>> multiple
>>>>> OS.  Its home page is broken at the moment, but the manual pages 
>>>>> work.
>>>>>
>>>>>    http://nasm.sourceforge.net/doc/html/nasmdoc0.html
>>>>
>>>> That's fine with me.  The instructions are in true intel mode now, 
>>>> the hard part will be to get the pseudo ops to match what the 
>>>> assembler expects.
>>>>
>>>> -Chris
>>>
>>> We had this discussion last year.  We need to support the assembler 
>>> that is guaranteed to be present as part of a tool chain, not every 
>>> assembler in existence.  On Unix, where we build with gcc, that is 
>>> gas.  On Windows, that is either again gcc or Visual Studio.  Visual 
>>> Studio also comes with an assembler, ml.exe, and users of Visual 
>>> Studio will not appreciate being forced to download a different 
>>> assembler.  I doubt anyone else would either. Gas is perfectly happy 
>>> assembling AT&T syntax,
>>
>> I agree with the above :)
>>
>>> so the only assembler that Intel syntax mode needs to support is 
>>> Mircosoft's ml.exe.
>>
>> I agree that "the most useful assembler for intel syntax mode to 
>> support is microsoft's ml.exe", but I don't think it's true that it 
>> is the only one we can/should support.  If there is little cost to 
>> adding NASM support (i.e. the code isn't horrible) and if someone 
>> produces a patch, we would be welcome it.
>>
>> That said, support for ml.exe certainly sounds more *useful*. :)
>>
>> -Chris
> It's not that I am dead set against supporting any other assembler, 
> it's just these sort of discussions always seem to degenerate into 
> "hey, we should support assembler X that I really like!", where X 
> ranges over a large set of assemblers.  The overwhelming majority of 
> LLVM users couldn't care which assembler is used so long as everything 
> "just works."  Heck, they don't care if an assembler is used at all.  
> In fact, they would be happier with LLVM if none were, as LLVM would 
> then run faster.  I'd rather all this energy was focused on producing 
> object files directly instead of supporting every assembler out 
> there.  Gas and ML are the two most useful to support, and the third 
> most useful is a very distant third and a pain to verify that it 
> continues to work with each new release.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>