>>> 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
On Tue, 12 Jul 2005, Aaron Gray wrote:>>> 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? > > RightThen 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 -- http://nondot.org/sabre/ http://llvm.org/
>>>> 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