Here is a mod to X86 that allows GAS to be used with MS Visual C++.
I introduces a ‘forWindows’ variable like ‘forCygwin’ in th X86SharedAsmPrinter class.
This may prompt thurther normalization, on the otherhand it may not 
Aaron
X86AsmPrinter.cpp (7.5 KB)
X86AsmPrinter.h (2.56 KB)
X86ATTAsmPrinter.cpp (5.42 KB)
X86IntelAsmPrinter.cpp (6.52 KB)
I have accidently left a ‘#include ’ in X86AsmPrinter.h
Aaron
Here is a mod to X86 that allows GAS to be used with MS Visual C++.
I introduces a 'forWindows' variable like 'forCygwin' in th X86SharedAsmPrinter class.
A couple of comments:
1. Please send patches instead of full files. The best way to do this is
to use CVS like this: 'cvs diff -u' in the directory that you care
about. You can also specify specific files to diff as well.
2. Please update to the latest CVS bits.
3. You need to invent a target triple for your new configuration. You'll
notice that the forCygwin/forDarwin variables are set based on the
target triple of the module... as you coded it, forWindows is only
ever set if the t-t is empty.
4. The name forWindows isn't very specific, as there are multiple dev
systems available on windows (including cygwin, mingw, masm, nasm,
etc). Please use something more specific.
5. I notice that the stuff you are controlling enables/disables the exact
same stuff as needed for cygwin. Will this change in the future?
This may prompt thurther normalization, on the otherhand it may not
Yes, I think it will. In particular, instead of a bunch of checks based on the target, what we really want is something like this:
... in the AsmPrinter ctor...
if (isDarwin) {
TargetUsesFooFeature = true;
TargetUsesBarFeature = true;
TargetUsesBazFeature = false;
} else if (isCygwin) {
...
}
etc.
Then instead of code that looks like this:
if (!forCygwin && !forDarwin && !forWindows && I->hasInternalLinkage())
O << "\t.local " << name << "\n";
We would have:
if (TargetUsesSymbolsMarkedLocal && I->hasInternalLinkage())
O << "\t.local " << name << "\n";
... or something.
-Chris
Here is a mod to X86 that allows GAS to be used with MS Visual C++.
I introduces a 'forWindows' variable like 'forCygwin' in th X86SharedAsmPrinter class.
A couple of comments:
1. Please send patches instead of full files. The best way to do this is
to use CVS like this: 'cvs diff -u' in the directory that you care
about. You can also specify specific files to diff as well.
Okay, I will do this in future, our posts crossed so I have not done that for the MASM backend.
I will do this in future. If you want me to redo the MASM Printer as diff's I can do so tommorow as it is late now.
2. Please update to the latest CVS bits.
Okay I may have been behind but am still not used to using CVS and how to reintegrate changes that go cross purpose with stuff I already have written but do not want to release yet. So I may have gotten out of sync here.
I resync'ed and make the changes for the MASM Printer again earlier, but did not do diff's.
3. You need to invent a target triple for your new configuration. You'll
notice that the forCygwin/forDarwin variables are set based on the
target triple of the module... as you coded it, forWindows is only
ever set if the t-t is empty.
Right, presumably Wndows does not set the TT. Should Windows or MSVC++ have one ?
If so how do I go about it. Maybe Jeff should be involved ?
4. The name forWindows isn't very specific, as there are multiple dev
systems available on windows (including cygwin, mingw, masm, nasm,
etc). Please use something more specific.
Maybe it should be MSVC specific then ?
5. I notice that the stuff you are controlling enables/disables the exact
same stuff as needed for cygwin. Will this change in the future?
Same as Cygwin, so MSVC++ build, gas generated code, can be run on gas.
This may prompt thurther normalization, on the otherhand it may not
Yes, I think it will.
... in the AsmPrinter ctor...
if (isDarwin) {
TargetUsesFooFeature = true;
TargetUsesBarFeature = true;
TargetUsesBazFeature = false;
} else if (isCygwin) {
...
}
etc.Then instead of code that looks like this:
if (!forCygwin && !forDarwin && !forWindows && I->hasInternalLinkage())
O << "\t.local " << name << "\n";We would have:
if (TargetUsesSymbolsMarkedLocal && I->hasInternalLinkage())
O << "\t.local " << name << "\n";... or something.
Yes that would be much better and more normalized.
Aaron
1. Please send patches instead of full files. The best way to do this is
to use CVS like this: 'cvs diff -u' in the directory that you care
about. You can also specify specific files to diff as well.Okay, I will do this in future, our posts crossed so I have not done that for the MASM backend. I will do this in future. If you want me to redo the MASM Printer as diff's I can do so tommorow as it is late now.
Sounds good, thanks and sorry for the trouble.
2. Please update to the latest CVS bits.
Okay I may have been behind but am still not used to using CVS and how to reintegrate changes that go cross purpose with stuff I already have written but do not want to release yet. So I may have gotten out of sync here.
Ok
3. You need to invent a target triple for your new configuration. You'll
notice that the forCygwin/forDarwin variables are set based on the
target triple of the module... as you coded it, forWindows is only
ever set if the t-t is empty.Right, presumably Wndows does not set the TT. Should Windows or MSVC++ have one ? If so how do I go about it. Maybe Jeff should be involved ?
It should/will. Currently there is no C/C++ front-end that works on native windows, but that doesn't really matter. In the future, we want to key off the target triple that makes sense.
Cygwin uses: i686-pc-cygwin and mingw uses i686-pc-mingw32, so I think that using i686-pc-masm and i686-pc-nasm make sense.
4. The name forWindows isn't very specific, as there are multiple dev
systems available on windows (including cygwin, mingw, masm, nasm,
etc). Please use something more specific.Maybe it should be MSVC specific then ?
Sure, but presumably you want to differentiate between nasm and masm (if they are not compatible) right?
5. I notice that the stuff you are controlling enables/disables the exact
same stuff as needed for cygwin. Will this change in the future?Same as Cygwin, so MSVC++ build, gas generated code, can be run on gas.
I don't understand.
This may prompt thurther normalization, on the otherhand it may not
Yes, I think it will.
...
Yes that would be much better and more normalized.
Nate said he might take a stab at this, which is the first step towards real subtarget support.
-Chris
1. Please send patches instead of full files. The best way to do this is
to use CVS like this: 'cvs diff -u' in the directory that you care
about. You can also specify specific files to diff as well.Okay, I will do this in future, our posts crossed so I have not done that for the MASM backend. I will do this in future. If you want me to redo the MASM Printer as diff's I can do so tommorow as it is late now.
Sounds good, thanks and sorry for the trouble.
No problem, we need proper proceedure in place to avoid possible confusion.
3. You need to invent a target triple for your new configuration. You'll
notice that the forCygwin/forDarwin variables are set based on the
target triple of the module... as you coded it, forWindows is only
ever set if the t-t is empty.Right, presumably Wndows does not set the TT. Should Windows or MSVC++ have one ? If so how do I go about it. Maybe Jeff should be involved ?
It should/will. Currently there is no C/C++ front-end that works on native windows, but that doesn't really matter. In the future, we want to key off the target triple that makes sense.
Cygwin uses: i686-pc-cygwin and mingw uses i686-pc-mingw32, so I think that using i686-pc-masm and i686-pc-nasm make sense.
Okay, how do we implement that ?
4. The name forWindows isn't very specific, as there are multiple dev
systems available on windows (including cygwin, mingw, masm, nasm,
etc). Please use something more specific.Maybe it should be MSVC specific then ?
Sure, but presumably you want to differentiate between nasm and masm (if they are not compatible) right?
Right
5. I notice that the stuff you are controlling enables/disables the exact
same stuff as needed for cygwin. Will this change in the future?Same as Cygwin, so MSVC++ build, gas generated code, can be run on gas.
I don't understand.
What this "patch" is for. Basically when a MSVC++ build lcc generates GNU as code.
This may prompt thurther normalization, on the otherhand it may not
Yes, I think it will.
...
Yes that would be much better and more normalized.
Nate said he might take a stab at this, which is the first step towards real subtarget support.
Great, it does need some attention.
Cheers,
Aaron
Right, presumably Wndows does not set the TT. Should Windows or MSVC++ have one ? If so how do I go about it. Maybe Jeff should be involved ?
It should/will. Currently there is no C/C++ front-end that works on native windows, but that doesn't really matter. In the future, we want to key off the target triple that makes sense.
Cygwin uses: i686-pc-cygwin and mingw uses i686-pc-mingw32, so I think that using i686-pc-masm and i686-pc-nasm make sense.
Okay, how do we implement that ?
In your LLC changes, just check for *-nasm and/or *-masm in the same places that *-darwin and *-cygwin are.
4. The name forWindows isn't very specific, as there are multiple dev
systems available on windows (including cygwin, mingw, masm, nasm,
etc). Please use something more specific.Maybe it should be MSVC specific then ?
Sure, but presumably you want to differentiate between nasm and masm (if they are not compatible) right?
Right
Then you need something more specific than 'isWindows'. I'd suggest, isNASM and isMASM.
5. I notice that the stuff you are controlling enables/disables the exact
same stuff as needed for cygwin. Will this change in the future?Same as Cygwin, so MSVC++ build, gas generated code, can be run on gas.
I don't understand.
What this "patch" is for. Basically when a MSVC++ build lcc generates GNU as code.
ok.
-Chris
Right, presumably Wndows does not set the TT. Should Windows or MSVC++ have one ? If so how do I go about it. Maybe Jeff should be involved ?
It should/will. Currently there is no C/C++ front-end that works on native windows, but that doesn't really matter. In the future, we want to key off the target triple that makes sense.
Cygwin uses: i686-pc-cygwin and mingw uses i686-pc-mingw32, so I think that using i686-pc-masm and i686-pc-nasm make sense.
Okay, how do we implement that ?
In your LLC changes, just check for *-nasm and/or *-masm in the same places that *-darwin and *-cygwin are.
Okay I will look into that tommorow.
4. The name forWindows isn't very specific, as there are multiple dev
systems available on windows (including cygwin, mingw, masm, nasm,
etc). Please use something more specific.Maybe it should be MSVC specific then ?
Sure, but presumably you want to differentiate between nasm and masm (if they are not compatible) right?
Right
Then you need something more specific than 'isWindows'. I'd suggest, isNASM and isMASM.
'for' rather than 'is'
forMSVC ? There is more to it than that 
I was going from the _WIN32 preprocessor symbol. So maybe 'forWIN32' if it is actually needed.
Aaron
Sure, but presumably you want to differentiate between nasm and masm (if they are not compatible) right?
Right
Then you need something more specific than 'isWindows'. I'd suggest, isNASM and isMASM.
'for' rather than 'is'
Yeah sorry.
forMSVC ? There is more to it than that
I was going from the _WIN32 preprocessor symbol. So maybe 'forWIN32' if it is actually needed.
I'll leave this to you and jeffc to hash out. I'll point out again that if NASM and MASM are not the same, that using 'win32' will not work, because it will be defined for both of them.
It looks like Nate just committed the subtarget support, so you might want to look at that.
-Chris
Chris Lattner wrote:
Jeff Cohen wrote:
Chris Lattner wrote:
Sure, but presumably you want to differentiate between nasm and masm (if they are not compatible) right?
Right
Then you need something more specific than 'isWindows'. I'd suggest, isNASM and isMASM.
'for' rather than 'is'
Yeah sorry.
forMSVC ? There is more to it than that
I was going from the _WIN32 preprocessor symbol. So maybe 'forWIN32' if it is actually needed.I'll leave this to you and jeffc to hash out. I'll point out again that if NASM and MASM are not the same, that using 'win32' will not work, because it will be defined for both of them.
It looks like Nate just committed the subtarget support, so you might want to look at that.
-Chris
_WIN32 is not suitable. It will also be defined for mingw, and as Chris pointed out it does not differentiate between NASM and MASM.
To check for being built by MSVC++, look for _MSC_VER. I'm not sure how to differentiate between gcc and mingw.
Use __MINGW32__ for mingw.
Also, I'm really not sure what the point is in supporting NASM. Anyone who has Visual Studio has MASM (or ML as it's now called) as well as VC++. Users of gcc/mingw will happily use gas. Who's going to bother getting NASM? VS-based developers will be annoyed enough as it is having to get bison/sed/flex.
Everyone seems to have missed the point. The "Mod for using GAS with MS VC++" as this thread is titled was what it was originally about and why I defined a 'forWindows' bool paralleling 'forCygwin' so that if you compiled for -x86-asm-syntax=attt|intel then the output would work with GAS under Cygwin or MinGW.
It was not a great "patch" as where ever forCygwin was I put a forWindows, so it needed a better neater solution.
Aaron