search for: nasmw

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

One more set of MSVC project updates. Changed ogg_static.lib to libogg_static.lib as that's the name latest version uses. Removed MSVC 6.0 related parts from README and tweaked info there to be more up-to-date. Also changed nasmw.exe into nasm.exe as nasmw.exe has been long gone. LibFLAC_dynamic was complaining in debug mode about conflicts with libcmt, I excluded it from the project there as I saw no other way to solve the problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_...

...SM" # PROP Default_Filter "nasm" # Begin Source File SOURCE=.\ia32\cpu_asm.nasm !IF "$(CFG)" == "libFLAC - Win32 Release" # Begin Custom Build InputPath=.\ia32\cpu_asm.nasm "ia32/cpu_asm.obj" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)" nasmw -f win32 -d OBJ_FORMAT_win32 -i ia32/ ia32/cpu_asm.nasm -o\ ia32/cpu_asm.obj !ELSEIF "$(CFG)" == "libFLAC - Win32 Debug" # Begin Custom Build InputPath=.\ia32\cpu_asm.nasm "ia32/cpu_asm.obj" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)" nasmw -f win32 -...

..., as I say if I can work with/under you on the Visual C++ 2003 > port then maybe we can get some real work done. Reid gave a good summary of what needs to be done. To that list I would add: * The X86 assembler printer needs to be modified to generate assembler code that works with NASMW. It currently generates assembler for the GNU assembler, gas. The goal is to use the GNU tool chain as little as possible when using VC++ for native builds. Microsoft's MASM isn't really an option because Microsoft stopped distributing it as part of Visual Studio...

...h/under you on the Visual C++ 2003 port >> then maybe we can get some real work done. > > Reid gave a good summary of what needs to be done. To that list I would > add: > > * The X86 assembler printer needs to be modified to generate > assembler code that works with NASMW. It currently generates > assembler for the GNU assembler, gas. The goal is to use the GNU > tool chain as little as possible when using VC++ for native > builds. Microsoft's MASM isn't really an option because Microsoft > stopped distributing it as part o...

...le so long as you are writing your own front end. There are serious technical issues standing in the way of getting llvm-gcc built natively on Windows. Also, only the JIT or interpreter is usable at this time. I haven't gotten around to getting assembler output yet that can be built with NASMW. > > >Marshall Spight > >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev > > > >

...is not changed from the standard Getting Started guide, as I understand it, except for the two sentences in bold: "Note: while you cannot do this step on Windows, you can do it on a Unix system and transfer hello.bc to Windows." and "Not currently possible, but eventually will use NASMW." As such, one cannot really "get started" using ONLY MinGW as their platform, so this entire section should be replaced with a paragraph to that effect, pointing the reader to the standard Getting Started guide for more info. -- Misha Brukman :: http://misha.brukman.net :: http:/...

...2003 port >>> then maybe we can get some real work done. >> >> Reid gave a good summary of what needs to be done. To that list I would >> add: >> >> * The X86 assembler printer needs to be modified to generate >> assembler code that works with NASMW. It currently generates ... > Okay, sounds interesting, but I am not familiar with GAS and NASM syntax, > only MASM. Never fond of AT&T syntax. Actually, AT&T vs Intel syntax is not the issue. LLC can already emit either syntax (-x86-asm-syntax={intel|att}). The missing pieces ar...

Hi LLVM'ers, Here is my second try to document, how to build the llvm system for MinGW on Windows. Henrik. ============================================================= Henrik Bach LLVM Open Source Developer e-mail: henrik_bach_llvm at hotmail.com ============================================================= 'Nothing is impossible; The impossible just takes longer time :)' -

On Fri, 21 Jan 2005 12:14:41 -0800, Reid Spencer <reid at x10sys.com> wrote: > > Sorry for the sad state of the cygwin build. I had hoped to have it > cleaned up by now but many other things have been taking my time. > Although the build has been succeeding in recent days, I'm not sure it > will buy you anything. NONE of the nightly tests pass on cygwin. <ulp!>

...#39;m confused. My understanding is that Visual C++ Express does not include Visual Studio, which is required to build LLVM. Anyway, assembly code generation is not yet supported using the Microsoft tool chain (as documented in the Getting Started with VS page), and when it is it will be with NASMW and not GCC. Not that any of this explains the "junk at the end of line" you got. Vyacheslav Akhmechet wrote: >I successfully compiled CVS HEAD yesterday on my win32 machine using >Visual C++ Express (2005). I also have Mingw tools installed. I wrote >a simple hello world app...

...ing Started guide, as I > >understand it, except for the two sentences in bold: > >"Note: while you cannot do this step on Windows, you can do it on a Unix >system and transfer hello.bc to Windows." > >and > >"Not currently possible, but eventually will use NASMW." > >As such, one cannot really "get started" using ONLY MinGW as their >platform, so this entire section should be replaced with a paragraph to >that effect, pointing the reader to the standard Getting Started guide >for more info. > > Sounds like these were c...

...hn Regehr, regehr at cs.utah.edu, Assistant Professor, School of Computing, University of Utah, posted it to this maining list some time ago, subject: "random testing". I just recyled it :) I was thinking of using Quest for getting the finer points of MS'es ABI tied down once the NASMW and MASM LLVM backends have been put together. It can compile dual test programs to check ABI and linking between two different compilers, real fun !:) 6. Design a simple recognisable logo. How about a "LLVM Inside" logo like the Intel one. Another project 'TAL' has used a sm...

Chris Lattner wrote: > On Thu, 9 Jun 2005, Alexander Friedman wrote: > >> On Jun 9, Chris Lattner wrote: >> >>>> I'm happy with .so. What purpose would .o files serve? >>> >>> >>> Speeds up compile time by not having to write out a .s file then run >>> the >>> system assembler on it. Likewise, emitting a .so file

>> 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, On Thu, Jun 02, 2005 at 10:38:58PM +0100, Aaron Gray wrote: > http://www.st.cs.uni-sb.de/~lindig/src/quest/ I don't know about Tanu, but we can certainly use this in finding bugs in LLVM! This has been listed as an "open project" for a long time [1], but someone already implemented it, saving us the time and effort. Thanks for the link! [1]

...gt; Janne Hyv?rinen wrote: > > > One more set of MSVC project updates. Changed ogg_static.lib to > > libogg_static.lib as that's the name latest version uses. Removed MSVC > > 6.0 related parts from README and tweaked info there to be more > > up-to-date. Also changed nasmw.exe into nasm.exe as nasmw.exe has been > > long gone. > > LibFLAC_dynamic was complaining in debug mode about conflicts with > > libcmt, I excluded it from the project there as I saw no other way to > > solve the problem. > > Applied. Thanks. > > Erik > -- &g...

On Mon, 16 May 2005, Alexander Friedman wrote: > Would it be possible (ie, relatively straitforward) to do the > following: Take the code in module A, compile it with the JIT (since > we cannot make libraries in Windows), and save the resulting binary > goo in some file. Later (in a different instance of the runtime), with > some much smaller sized loader, read in the file and link

Hi list, The short version of my question: Is it easy to make a lightweight (read: small in size) linker loader for code produced by the llvm jit. Does it even make sense to do so? The longer version: Suppose I have some llvm bytecode module A, and I want to load and use that code in some runtime. The two obvious ways to do that are a) use the LLVM jit, or b) compile the module into a dynamic

...have to think about it when I am more familiar with LLVM >> and >> know the ground better. But if you have any reasonably small/incremental >> tasks that need doing then I am open to that. > > I would suggest working on the AsmWriter to get it to emit directives that > NASMW likes. This should just be a matter of doing the following steps: > > 1. Define a new subclass of X86IntelAsmPrinter in the > lib/Target/X86/X86AsmPrinter class, name it X86NASMAsmPrinter or > something. > 2. In the subclass, change any behaviors that you don't like (e.g....