MASM Backend

Here’s the new MASM backend.

It has the following files :-

lib/Target/X86/X86AsmPrinter.h
lib/Target/X86/X86AsmPrinter.cpp
lib/Target/X86/X86MASMPrinter.h

lib/Target/X86/X86MASMPrinter.cpp
lib/Target/X86/X86.td
lib/Target/X86/X86InstrInfo.td
lib/Target/X86/makefile
Makefile.rules
win32/x86/x86.vcproj

X86AsmPrinter.{cpp|h} - have new variable ‘forWindows’ added which fits in with working with GAS on MSVC++ build. X86AsmPrinter.cpp also has the new ‘masm’ target added.

X86MASMPrinter.{cpp|h} - X86MASMPrinter class

X86.td, X86InstrInfo.td, makefile, Makefile.rules - have new GenAsmWriter2.inc target added.

win32/x86/x86.vcproj - Windows project update

I am releasing this now, but I will be releasing a testset for it soon as well.

An unofficial version of MASM is availiable on the web from www.masm32.com.

Aaron

MASM.tar.gz (32.7 KB)

Hi LLVM'ers,

has anyone read the license details for MASM32 and understood how these fit in with Open Source projects, especially GPL? - As far as I can see - no one is allowed to license projects under GPL or at worst other OS licenses nor the deritives of the project, if you're using MASM32.

Are the MASM backend compatible with the MS version of MASM or other not so license restrictive versions of or similar to MS MASM?

Henrik.

Henrik Bach wrote:

Hi LLVM'ers,

has anyone read the license details for MASM32 and understood how these fit in with Open Source projects, especially GPL? - As far as I can see - no one is allowed to license projects under GPL or at worst other OS licenses nor the deritives of the project, if you're using MASM32.

Are the MASM backend compatible with the MS version of MASM or other not so license restrictive versions of or similar to MS MASM?

Henrik.

=============================================================
Henrik Bach
LLVM Open Source Developer

e-mail: henrik_bach_llvm at hotmail.com

I see no reason to use the "unofficial" MASM32 anymore than to use NASM. Owners of Visual Studio have the official MASM, and users of gcc/mingw have gas.

Hello, Henrik.

You wrote Tuesday, July 12, 2005, 3:49:07 PM:

Are the MASM backend compatible with the MS version of MASM or other not so
license restrictive versions of or similar to MS MASM?

Btw, maybe, it will be fine, if this backend will be tested for work
with YASM? (The Yasm Modular Assembler Project). It seems, that
YASM grows fast during last months. It also supports AMD64 syntax, which
might be helpful....

Henrik Bach wrote:

has anyone read the license details for MASM32 and understood how these
fit in with Open Source projects, especially GPL?

A dangerous question there... :slight_smile:

The Trolltech folks believe the license for VC++ prevents you from using
GPL'd software which is why they don't initially support MS compilers in
their GPL'd Windows version of Qt4 (which they just released). Its another
one of those arguments over word definitions that won't really go away
until MS makes its intent clear, either by clarification on one hand, or
lawsuits on the other. :slight_smile: MS DOES have some explicit anti-open source
language in their license, but no one was sure at the time this debate
occurred (when Trolltech announced Qt4 for Windows without initial support
for MS compilers) what its full scope was/is. On the other hand, MS is
only really gunning for the GPL, not stuff like LLVM that is under a more
permissive license, so I'm not sure there is any real problem here for
LLVM.

I have to agree with Jeff on this, if NASM support is only intended for
Windowsland, I don't really see the point, just support ML instead. If
NASM support is intended for *nixland too, then why not support YASM
instead? YASM has got AMD64 support that NASM doesn't and its supposedly
an improvement over NASM (I don't know for a fact - just what I've read).
My question would be is there something GAS doesn't do (or do well) that is
the reason why NASM support is wanted as well? Since the LLVM system, like
GCC, is designed to spit out correct assembly thats not really meant for
human consumption (immediately fed to the assembler and then normally
thrown away), is there any reason to support any assembler beyond the
"standard" one for the system in question (gas on *nix/cygwin, ML on win)?