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.
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 > > >
Hi Jeff,> 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.Personally, I'm not fussed if the Intel assembly output can be assembled with a particular assembler; I'm interested in having a `readable' assembly output to examine what x86 code is being produced by the back-end. Speaking of which, has there ever been any consideration to producing hex constants in the various text outputs for values that look better in hex, e.g. 65280 is 0xff00. There's probably some tests that could be done before default to decimal. Cheers, Ralph.
> 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.I got the code I did from the mailing list. It needs some reworking as I created another TableGen identity. Its attached. If you can wait a week (as I am on another project at the moment) I will be able to do that. Aaron -------------- next part -------------- A non-text attachment was scrubbed... Name: MASM.tar.gz Type: application/x-gzip Size: 33434 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060502/b42b5420/attachment.bin>