Well that's the price you pay for mixing C and assembler. Change the compiler, and you're hosed.
Besides, even if gcc accepted the syntax, the way gcc inline asm accesses local variables is also different.
The first question is why you have so much assembly code?
If it was to address some performance problem, when did you last assess the performance, and can you now get away with having more of the asm code written in C.
The performance profile is going to change anyway by changing the compiler, so I'd suggest you start with a fresh baseline of all the asm code written as 'C', then figure out what really needs to be converted back to asm. In particular, gcc has a vast array of optimisation flags to play with. With any luck, you'll save yourself a lot of work in not maintaining assembler code.
If there is some essential asm - like messing with certain processor registers which are physically inaccessible to C, then wrap them up in very small C functions which perform only the necessary asm instructions. Collect all such functions into one or two source files. This limits the scope of your future re-work, say changing processors next time.
AFAIK, there is only flexible asm notation for Intel x86, presumably because there were enough people to whine about it to get something done about it.
Code:
#include<stdio.h>
#include<stdlib.h>
int foo ( void ) {
int result = 0;
#ifdef USE_INTEL
asm (".intel_syntax noprefix\n\t"
"mov %%eax,0x12345678\n\t"
"mov %0,%%eax\n"
:"=r"(result)
:
:"%eax"
);
#else
asm ("movl $0x12345678,%%eax\n\t"
"movl %%eax,%0\n"
:"=r"(result)
:
:"%eax"
);
#endif
return result;
}
int main ( ) {
printf("%x\n",foo());
return 0;
}
$ gcc foo.c && ./a.exe
12345678
$ gcc -masm=intel -DUSE_INTEL foo.c && ./a.exe
12345678
gcc asm code syntax
