[LLVMdev] Intel vs. AT&T Assembly.

Jeff Cohen jeffc at jolt-lang.org
Mon May 1 12:58:46 PDT 2006

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.

More information about the llvm-dev mailing list