similar to: [LLVMdev] Re: ELF / COFF Interface

Oh, so *that's* what happened to MASM. OK, change of plans. Forget NASMW, target ML. Aaron Gray wrote: >>> We still have a dependency on the system linker, but in time that >>> could be addressed. Note that VC++ distributes a native linker, but >>> I don't think it distributes a native assembler (I could be wrong >>> though). >> >>

>> We still have a dependency on the system linker, but in time that >> could be addressed. Note that VC++ distributes a native linker, but I >> don't think it distributes a native assembler (I could be wrong though). > > You are correct. Microsoft does not distribute an assembler with Visual > Studio anymore (hasn't for some time). Its called ML.EXE now

Aaron Gray wrote: >> GCC is smart enough to realize it doesn't return. That's because the >> declaration of abort() is decorated with __attribute__((__noreturn__)). >> >> So is GCC smarter than VC++? As it turns out, in VC++ the >> declaration of abort() is decorated with __declspec(noreturn). >> >> Whidbey is not stricter than 2003, it is

>> I thought Whidbey would really be upto the job, obviously not. > > Well, we don't know until someone tries. Oh, well we have got a bug to report to Microsoft then ! I still may carry on implementing any mods on the VS2003 port over to 2005 so we know where we are with that. There may well be a second beta so it would be good to get any problems in and reported to Microsoft in

On Fri, 18 Feb 2005, Aaron Gray wrote: >>> I thought Whidbey would really be upto the job, obviously not. >> >> Well, we don't know until someone tries. > > Oh, well we have got a bug to report to Microsoft then ! > > I still may carry on implementing any mods on the VS2003 port over to 2005 > so we know where we are with that. There may well be a second

Jeff Cohen wrote: > Chris Lattner wrote: > >> On Tue, 12 Jul 2005, Aaron Gray wrote: >> >>>>>> Sure, but presumably you want to differentiate between nasm and >>>>>> masm (if they are not compatible) right? >>>>> >>>>> >>>>> >>>>> Right >>>> >>>>

> GCC is smart enough to realize it doesn't return. That's because the > declaration of abort() is decorated with __attribute__((__noreturn__)). > > So is GCC smarter than VC++? As it turns out, in VC++ the declaration of > abort() is decorated with __declspec(noreturn). > > Whidbey is not stricter than 2003, it is merely buggier. VC++ has always > complained

On 01/28/2010 11:41 AM, Anton Korobeynikov wrote: > > The required efforts equal to ones required to write new assembler. > "Too weak to be usable" means "it's not possible to represent many > important constructs with masm/nasm/fasm". Wow. It's perhaps too much of a distraction, but I'm curious about the details of this. It's probably because

On Jan 28, 2010, at 11:51 AM, Dustin Laurence wrote: > On 01/28/2010 11:41 AM, Anton Korobeynikov wrote: >> >> The required efforts equal to ones required to write new assembler. >> "Too weak to be usable" means "it's not possible to represent many >> important constructs with masm/nasm/fasm". > > Wow. It's perhaps too much of a

GCC is smart enough to realize it doesn't return. That's because the declaration of abort() is decorated with __attribute__((__noreturn__)). So is GCC smarter than VC++? As it turns out, in VC++ the declaration of abort() is decorated with __declspec(noreturn). Whidbey is not stricter than 2003, it is merely buggier. VC++ has always complained about functions failing to return a

On Jun 16, 2009, at 3:12 PM, David Greene wrote: > On Tuesday 16 June 2009 09:48, Aaron Gray wrote: > >> Appently the GAS Intel backend has flaws and does not work >> correctly anyway >> so the X86IntelAsm backend is designed only to target MASM anyway. > > gas Intel syntax is indeed broken in LLVM. I'd love to make it work > but > my work has not

Chris Lattner wrote: > On Tue, 12 Jul 2005, Aaron Gray 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

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

Hi LLVM'ers, has anyone read the license details for MASM32 and understood how these fit in with Open Source projects, especially GPL? - As far as I can see - no one is allowed to license projects under GPL or at worst other OS licenses nor the deritives of the project, if you're using MASM32. Are the MASM backend compatible with the MS version of MASM or other not so license

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

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

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

Here's the new MASM backend. It has the following files :- lib/Target/X86/X86AsmPrinter.h lib/Target/X86/X86AsmPrinter.cpp lib/Target/X86/X86MASMPrinter.h lib/Target/X86/X86MASMPrinter.cpp lib/Target/X86/X86.td lib/Target/X86/X86InstrInfo.td lib/Target/X86/makefile Makefile.rules win32/x86/x86.vcproj

On Tuesday 16 June 2009 09:48, Aaron Gray wrote: > Appently the GAS Intel backend has flaws and does not work correctly anyway > so the X86IntelAsm backend is designed only to target MASM anyway. gas Intel syntax is indeed broken in LLVM. I'd love to make it work but my work has not (yet) allocated time for that. Maybe I can hack LLVM on the weekends. :) The above discussion leads

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: