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. > > -ChrisWe 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, so the only assembler that Intel syntax mode needs to support is Mircosoft's ml.exe.
Hi, There maybe licencing problems with ML/MASM, we need to get someone to check this out if we are going to support them. NASM and YASM were suggested. Aaron
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 -- http://nondot.org/sabre/ http://llvm.org/
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*. :) > > -ChrisIt'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.