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

[Aaron Gray]

>>> 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