[LLVMdev] Mod for using GAS with MS VC++

Chris Lattner sabre at nondot.org
Mon Jul 11 17:21:11 PDT 2005


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/




More information about the llvm-dev mailing list