similar to: [LLVMdev] Intel vs. AT&T Assembly.

The Intel version is just a clone of the AT&T version at this time. No one has yet taken the time to make it produce actual Intel syntax. Ralph Corderoy wrote: > Hi, > > I notice `lli -print-machineinstrs -x86-asm-syntax=(att|intel)' both > prefix registers with `%'. Is this right? I thought AT&T did this and > Intel didn't. The GNU gas manual concurs. >

Hi Jeff, > > I notice `lli -print-machineinstrs -x86-asm-syntax=(att|intel)' both > > prefix registers with `%'. Is this right? I thought AT&T did this > > and Intel didn't. The GNU gas manual concurs. > > > > http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_chapter/as_16.html > > The Intel version is just a clone of the

We know. Someone offered to do the Intel version, but did little more than a huge cut and paste of the AT&T version and then lost interest. No one else has had the time or inclination to finish the (barely begun) job. Patches accepted :) Ralph Corderoy wrote: > Hi, > > >> It's a long way towards it: >> >> # AT&T. # Intel.

Hi Chris, > The LLVM X86 backend started out emitting intel mode for use with GAS > and it's "intel syntax mode" (which does use registers with %'s). > Unfortunately GAS has (or commonly available versions have) a number > of bugs in intel syntax mode (e.g. you can't define a function named > 'dword'), so we switched to using AT&T syntax. Ah, OK.

On Sat, 29 Apr 2006, Jeff Cohen wrote: > We know. Someone offered to do the Intel version, but did little more than a > huge cut and paste of the AT&T version and then lost interest. No one else > has had the time or inclination to finish the (barely begun) job. Patches > accepted :) Actually, that's not true. The LLVM X86 backend started out emitting intel mode for

Hi, > It's a long way towards it: > > # AT&T. # Intel. > .text .text > .align 16 .align 16 > .globl main .globl main > .type main, @function > main: main: >

On Mon, 1 May 2006, Ralph Corderoy wrote: >> The LLVM X86 backend started out emitting intel mode for use with GAS >> and it's "intel syntax mode" (which does use registers with %'s). >> Unfortunately GAS has (or commonly available versions have) a number >> of bugs in intel syntax mode (e.g. you can't define a function named >> 'dword'),

Dear LLVM guys, I've solved my problem with the passes, and compiled my first code using the new register allocator! Debugging was quite easy, using gdb. The problem was that I was forgetting to initialize the array that records the physical registers ever used (MachineFunction::UsedPhysRegs). This is a very minor thing, but I would suggest asserting that the vector has been initialized

On Fri, 23 Jun 2006, Fernando Magno Quintao Pereira wrote: > I am getting an error with my pass implementation, and I cannot figure > it out. Basically, I've implemented part of a register allocation > algorithm, but I am having problems to set the passes correctly. For > instance, for this program below, the following error message is > produced: It's hard to say

Dear LLVM guys, I am getting an error with my pass implementation, and I cannot figure it out. Basically, I've implemented part of a register allocation algorithm, but I am having problems to set the passes correctly. For instance, for this program below, the following error message is produced: .c ----------------------| .bc ---------------------------------

Vyacheslav, I've tracked down the change and I have a fix for you to test. The attached patch should be applied to the CVS head (version 1.132) of X86AsmPrinter.cpp in llvm/lib/Target/X86. The patch just includes MINGW targets in the same set of choices that it makes for Cygwin. Could you please try the patch and let me know if it solves your problem? If it does, I'll commit the patch.

Reid, This patch won't work for me. I compile llvm toolset with MSVC Express (hence __MINGW32__ won't be defined for me at compile time). I only try to feed the generated assembly into gcc (pretty much gnu assembler, I suppose). I don't use mingw tools at the earlier stage. However it's obvious for me how to modify the code now (just add MSVC at that line), thanks! I'll try it

Hi: I've been able to compile the attached "helloworld.c" file converted from "helloworld.cpp". My question is how does one usually use __main() and CODE_FOR_MAIN() in tying up with the rest of the code? Attached here are the original "helloworld.cpp" and "helloworld.c" files. Thanks. Napi On Sun, 2006-11-05 at 09:14 -0800, Reid Spencer wrote: >

Ok, I got home so I have more details. Here's the sample C program: ----------------- C program --------------- #include <stdio.h> int main() { printf("hello world\n"); return 0; } ------------- end C program ------------- This is compiled using llvm online demo into the following llvm code (target removed): ----------------- LLVM code -------------- deplibs

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 application and generated native assembly code using llvm. When I tried to feed the code into GCC, it rejected it with "junk at the end of line" error messages. Shouldn't GCC be able to assemble this code? I realize win32 port

Vyacheslav, This is the same problem that I had with Cygwin .. nearly identical. The issue was documented in PR492 if you want some background. I'm currently trying to dig up what I did to fix this in December for Cygwin and see if I can apply the same change for mingw. Reid. On Mon, 2005-03-07 at 16:39, Vyacheslav Akhmechet wrote: > Ok, I got home so I have more details. Here's the

Hi Napi, On Mon, 2006-11-06 at 10:44 +0800, Mohd-Hanafiah Abdullah wrote: > Hi: > > I've been able to compile the attached "helloworld.c" file converted > from "helloworld.cpp". Great. > > My question is how does one usually use __main() and CODE_FOR_MAIN() > in tying up with the rest of the code? I'm not quite sure what you're asking.

Chris Lattner wrote: > On Mon, 1 May 2006, Ralph Corderoy wrote: > >> >> NASM might be the nicer target since it's GNU LGPL and runs on multiple >> OS. Its home page is broken at the moment, but the manual pages work. >> >> http://nasm.sourceforge.net/doc/html/nasmdoc0.html > > That's fine with me. The instructions are in true intel mode now,

Ok, I just tried the patch with some modifications (added msvc target and used WIN32 instead of __MINGW32__ for preprocessor) and everything worked beautifully. Thanks for the help! On Mon, 7 Mar 2005 20:45:40 -0500, Vyacheslav Akhmechet <coffeemug at gmail.com> wrote: > Reid, > > This patch won't work for me. I compile llvm toolset with MSVC Express > (hence __MINGW32__

On Mon, 1 May 2006, Jeff Cohen wrote: > Chris Lattner wrote: >> On Mon, 1 May 2006, Ralph Corderoy wrote: >>> NASM might be the nicer target since it's GNU LGPL and runs on multiple >>> OS. Its home page is broken at the moment, but the manual pages work. >>> >>> http://nasm.sourceforge.net/doc/html/nasmdoc0.html >> >> That's