[LLVMdev] x86 Intel Syntax and MASM 9.x
Eli Friedman
eli.friedman at gmail.com
Mon Jun 15 18:43:56 PDT 2009
On Mon, Jun 15, 2009 at 5:49 PM, Gaster,
Benedict<Benedict.Gaster at amd.com> wrote:
> I would like to use the LLVM x86 code generator to emit Intel syntax that is
> compatible with Microsoft’s MASM 9.x. Taking the TOT LLVM, from last week, I
> have found a number of changes that are required to make this work, most of
> which are straight forward but a couple I wanted to check with the group to
> see what people thought was the best thing to do. In particular, I have made
> all necessary changes and these are mostly constrained to the files:
>
>
>
> X86IntelAsmPrinter.[h|cpp]
>
> X86TargetAsmInfo.[h|cpp]
Sounds good; did you mean to attach a patch? It'll be easier to
discuss with that. (The output of "svn diff" is fine.)
> The main problem that I have hit is regarding the use of CL register in the
> shift instructions. The problem is that ATT syntax states that it should be
> referenced as “%cl” while Intel says just “cl” but these references occur in
> X86InstInfo.td and this means that it is shared between Intel and ATT
> printing! For example, the shift rules:
We have two different output styles for precisely that reason.
> The problem is that it does not make sense to have separate rules for Intel
> and ATT and as such I wanted to get the lists advice on what people think is
> the best approach to resolving this issue so I can make the changes?
The changes just mentioned looks correct.
> It is also worth noting that MASM does not allow:
> shr ESI
> to be mean shift by 1 and instead I have to emit:
> shr ESI, 1
> which I’m assuming is not an issue?
That's fine.
> Finally, as far as I can tell from comments on the mailing list the current
> Intel syntax emitted by LLVM does not work with any particular Window’s
> assembler and so making these changes will not cause another path to stop
> working, is this correct?
MASM is about as canonical as it gets for standard Intel syntax, and
the changes look reasonable.
-Eli
More information about the llvm-dev
mailing list