similar to: [LLVMdev] Re: NASM Backend

Hi again, I have put together a "blank skeleton" for a X86NASMPrinter class, with effectively the same behaviour as the X86IntelAsmPrinter class. I had to do this within the X86AsmPrinter.cpp file rather than as a separate source file as the dependancies were so. Please do not commit this yet, I have included it not for confidence sake :)) I do not know whether it is a good idea to

On Tue, 10 May 2005, Aaron Gray wrote: > I have put together a "blank skeleton" for a X86NASMPrinter class, with > effectively the same behaviour as the X86IntelAsmPrinter class. I had to > do this within the X86AsmPrinter.cpp file rather than as a separate > source file as the dependancies were so. Please do not commit this yet, > I have included it not for

I am now getting the following link errors on all executables: x86.lib(X86AsmPrinter.obj) : error LNK2001: unresolved external symbol "public: virtual bool __thiscall llvm::x86::X86ATTAsmPrinter::runOnMachineFunction(class llvm::MachineFunction &)" (?runOnMachineFunction at X86ATTAsmPrinter@x86 at llvm@@UAE_NAAVMachineFunction at 3@@Z) x86.lib(X86AsmPrinter.obj) : error LNK2001:

Fixed it. You did not add the new files to Visual Studio (or at least forgot to include x86.vcproj with the other files). Jeff Cohen wrote: > I am now getting the following link errors on all executables: > > x86.lib(X86AsmPrinter.obj) : error LNK2001: unresolved external symbol > "public: virtual bool __thiscall > llvm::x86::X86ATTAsmPrinter::runOnMachineFunction(class

>> I am not really sure whether to do a X86NASMPrinter or whether to bypass >> that for now and work on an X86COFFWriter which would be more useful to >> me ? > > I wouldn't suggest writing an X86NASMPrinter: just change the current > Intel printer to do what you want. Noone is currently using the intel > printer, so you can do what you wish to it. Once I

Hi all, Well, suggestion for workarounds for the namespace problems are welcome... this is a 7 minutes compile files on a pentium 4 3ghz 700Mb ram... The fatal error at the end MAY depend on the previous... or at least, I hope so. cl /nologo /TP /EHsc /GR /Zi /Yd /D__STDC_LIMIT_MACROS /DHAVE__FINITE_IN_FLOAT_H /DHAVE__ISNAN_IN_FLOAT_H /ISTLport-4.6.2\stlport /Illvm\inc lude

struct X86AsmPrinter is in an anonymous namespace, but printInstruction is declared in namespace llvm. try editing the tablegen output to move X86AsmPrinter::printInstruction into an anonymous namespace, not llvm. I suspect this will at least fix the first problem. Then we can figure out the proper longterm fix. Andrew On Tue, 2004-10-12 at 03:56, Paolo Invernizzi wrote: > Hi all, >

Chris, Okay, I have done as you have requested. The only thing I did not like was a clsh between the enum X86 and the new namespace X86, which I had to rename as x86 :( Anyway, I suppose the lower case 'x' in 'x86' fits in with the lowercase 'llvm' namespace. Build tested on MS VC2003 and Linux. Aaron -------------- next part -------------- A non-text attachment was

On Sat, 2 Jul 2005, Aaron Gray wrote: >>> The only thing I did not like was a clsh between the enum X86 and the new >>> namespace X86, which I had to rename as x86 :( >>> >>> Anyway, I suppose the lower case 'x' in 'x86' fits in with the lowercase >>> 'llvm' namespace. >> >> I'm not sure I follow. X86 is a

>> 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 lue of >> that. > > ok. If both you and Jeff are okay with still implementing a VC2005 version spawning off changes to the VC2003 port

On Tue, 12 Jul 2005, Aaron Gray wrote: >>>> You shouldn't have to add new classes to the .td file, just modify >>>> printOp for your asmprinters. >>> I dont think printOp is virtual and therefore cannot be overriden ? >> Why does it need to be virtual? No 'intel' printers want % signs. > > The GAS intel code generator generates percents,

>> The GAS intel code generator generates percents, look at the >> X86InstrInfo.td file it is full of them. > > Ah, I see what you're talking about. Please feel free to remove all of > those from the Intel format. For example, change this: > > def IN8rr : I<0xEC, RawFrm, (ops), > "in{b} {%dx, %al|%AL, %DX}">, Imp<[DX],

> Patch committed here: Just looked at the WebCVS. > I made a couple of changes to the code you submitted. The most important > is that I converted this (in the .h files): > > using namespace llvm; > namespace x86 { > ... > > into: > > namespace llvm { > namespace x86 { > ... Right, that is how I had it in the beggining, obviously I miss understood your

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:

On Tue, 12 Jul 2005, Aaron Gray wrote: >>> X86InstrInfo.td file it is full of them. >> >> Ah, I see what you're talking about. Please feel free to remove all of >> those from the Intel format. For example, change this: >> >> def IN8rr : I<0xEC, RawFrm, (ops), >> "in{b} {%dx, %al|%AL, %DX}">, Imp<[DX],

>>> You shouldn't have to add new classes to the .td file, just modify >>> printOp for your asmprinters. >> >> I dont think printOp is virtual and therefore cannot be overriden ? > > Why does it need to be virtual? No 'intel' printers want % signs. The GAS intel code generator generates percents, look at the X86InstrInfo.td file it is full of

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

On Thu, 30 Jun 2005, Aaron Gray wrote: > I have "refactored" the X86AsmPrinter into a number of files ready for > the MASM and NASM backends to be added. Nice! > There is a new namespace llvm::X86 to replace the anomonous namespace as > this does not work accross mutiple .h and .cpp files. Other than that > everything is pritty straight forward, t may possibly need

Builds fine on Linux, but there seems to be a problem building it on Cygwin, will look into this. Aaron ----- Original Message ----- From: Aaron Gray To: LLVM Developers Mailing List Sent: Thursday, June 30, 2005 7:12 PM Subject: [LLVMdev] X86AsmPrinter + MASM and NASM backends I have "refactored" the X86AsmPrinter into a number of files ready for the MASM and NASM

Some wheird problem, Target/X86 builds okay now. But there seems to be another problem with the Cygwin build :- make[4]: Entering directory `/usr/build/llvm/lib/Target/SparcV9/ModuloScheduling' llvm[4]: Compiling ModuloSchedulingSuperBlock.cpp for Debug build /usr/src/llvm/lib/Target/SparcV9/ModuloScheduling/ModuloSchedulingSuperBlock.cpp : In member function `virtual bool