<div dir="ltr"><div class="gmail-adn gmail-ads" style="border-left:none;padding:0px;display:flex;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><div class="gmail-gs" style="margin:0px;padding:0px 0px 20px;width:820.229px"><div class="gmail-"><div id="gmail-:cov" class="gmail-ii gmail-gt" style="font-size:0.875rem;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="gmail-:cow" class="gmail-a3s gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div dir="ltr">Hi all,<div><br></div><div>I'm proposing to add MASM support to LLVM's assembler capabilities, which should nearly complete LLVM's support for cross-platform Windows compilation.</div><div><br></div><div>Goal: Match the functionality of Microsoft's ml.exe and ml64.exe.</div><div></div><div><br></div><div>I'm currently trying to implement this as a set of extensions to the assembler; it will correctly handle assembly files containing both GNU and MASM syntax.</div><div></div><div><br></div><div>The features would be added to AsmParser and controlled via MCAsmInfo, and would be available through both llvm-mc and clang. Both tools would remain able to parse GNU-syntax assembler, but when passed the appropriate flags, would also handle MASM. My first thought is to trigger MASM support whenever we're targeting Windows, but we could also make it a discrete function controlled by a different command-line flag.</div><div><br></div><div>We will also define a new driver (llvm-ml) that matches the command-line interface of ml.exe and/or ml64.exe. This will likely be similar to clang-cl and llvm-lib in building on top of a previous driver: either llvm-mc or clang.</div><div><br></div><div>Known obstacles:</div><div>1. Support for "ifdef <register>": already completed, with a new tryParseRegister method added to all TargetAsmParsers.</div><div>2. Syntax variations: MASM uses infix notation for many directives, and does not use "."-prefixes on its directives.</div><div>3. Macro functions: MASM includes macro functions, which can emit parameters and not just full instructions. (Probably tricky.)</div><div>4. Richer macro language in general: some MASM files rely heavily on text-substitution for named symbols, as well as resolution of fields in STRUCTs.</div><div><br></div><div>3 & 4 might be best handled by adding a preprocessor stage, but the syntax is not similar to the C preprocessor... I'm going to try to augmenting existing macro support first.</div><div><br></div><div>Any obstacles I've missed, or critiques of the approaches, would be very welcome!</div><div><br></div><div>Thanks,</div><div>- Eric Astor</div></div></div></div></div></div></div></div>