>> 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 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.Yes that would be much better and more normalized. Aaron
On Tue, 12 Jul 2005, Aaron Gray wrote:>> >> 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. :) In particular, instead of a bunch of checks >> based on the target, what we really want is something like this:...> 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 -- http://nondot.org/sabre/ http://llvm.org/
>>> 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. :) In particular, instead of a bunch of checks >>> based on the target, what we really want is something like this: > > ... > >> 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