Hi Chris,> The LLVM X86 backend started out emitting intel mode for use with GAS > and it's "intel syntax mode" (which does use registers with %'s). > Unfortunately GAS has (or commonly available versions have) a number > of bugs in intel syntax mode (e.g. you can't define a function named > 'dword'), so we switched to using AT&T syntax.Ah, OK. The current gas manual says Intel register operands are undelimeted, i.e. no `%'. Perhaps they've changed. http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_chapter/as_16.html#IDX585> Intel syntax mode was retained because it's nicer to read :), and > because it may be useful in the future. As Jeff says, patches are > welcome to make it do something useful, e.g. be assemblable with MASM > or NASM.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 You went onto write:> > Let's see. Ralph correctly points out that LLVM isn't producing > > anything like Intel syntax. ..."Oh, no I didn't". :-) It was me that was saying llc's att and intel are already very different but both happen to have `%'.> This is not true. LLVM produces something very close to what GAS > accepts in intel mode: that is, we produce fully intel syntax (e.g. > "DWORD PTR", no opcode size suffixes, etc) but we prepend % onto > registers. This is what GAS expects (i.e., it's gas intel mode). I > believe there is a GAS option to turn off the % prefix, but we never > used it because it had other bugs.OK, looks like they may have made that the default now.> As was independently pointed out, we're quite close to supporting MASM > (or whatever) intel syntax. Removing the %'s, for example, is > trivial. Anyone who wants to do so is welcome to. The current > -x86-asm-syntax=intel support is not currently compatible with any > assembler that I know of. Patches to make it useful are welcome.OK. Thanks for clarifying. Cheers, Ralph.
On Mon, 1 May 2006, Ralph Corderoy wrote:>> The LLVM X86 backend started out emitting intel mode for use with GAS >> and it's "intel syntax mode" (which does use registers with %'s). >> Unfortunately GAS has (or commonly available versions have) a number >> of bugs in intel syntax mode (e.g. you can't define a function named >> 'dword'), so we switched to using AT&T syntax. > > Ah, OK. The current gas manual says Intel register operands are > undelimeted, i.e. no `%'. Perhaps they've changed. > > http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_chapter/as_16.html#IDX585Though it really doesn't matter, IIRC, this was to work around bugs in GAS. In particular (again, as I recall, could be wrong), GAS accepted registers either with or without % prefixes. If you used % prefixes, it avoided some class of bug that I don't remember any longer. If you dig into the CVS history, looking at the commit that added the % prefixes, it will probably explain in further detail. In any case, I committed a patch to remove the %'s from register names in intel mode.>> Intel syntax mode was retained because it's nicer to read :), and >> because it may be useful in the future. As Jeff says, patches are >> welcome to make it do something useful, e.g. be assemblable with MASM >> or NASM. > > 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.htmlThat'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 -- http://nondot.org/sabre/ http://llvm.org/
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.