Intel Compiler/Assembler taking care GNU-style (GAS) "movq/movslq/movss/movsd" calls

Intel Compiler/Assembler taking care GNU-style (GAS) "movq/movslq/movss/movsd" calls

Hello,

Intel C++ Compiler generates GNU-style assembly (AT&T).S file as an output file when done as "icpc -fasm-blocks test.cc -S", normally the common MOV instructions are - movq, movslq, movss, movsd, movntq, movntdq, etc.

But when one has to write Inline assembly file using Intel-syntax (NASM) by having the above .S output file as reference, how does assembler used by Intel takes care the difference between NASM & AT&T syntax. Even, I write the input Inline Assembly file using NASM syntax, the output .S assembly file and disassembly file both are generated in GNU-style syntax. How does this transfer happens internally?

How does one take care theGNU-styleall MOV (movq, movslq, movss, movsd, etc.)instructions syntaxw.r.t toIntel syntax(NASM), like movq in GNU-style has to be written as mov in NASM(Intel) syntax where the type of long, quad, etc. in Intel syntax is taken care by automatically?

Do Intel has some table for instructions conversion ofGNU-style Assembly(GAS/AT&T) to Intel Assembly(NASM)?

~BR
Mukkaysh Srivastav

5 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

The Intel C++ compiler support inline assembly. In Linux platform the compiler by default assumes that you are using the AT &T (GNU style Assembly). You can also use Microsoft style assembly syntax but you need to tell the compiler for the same using option use-msasm.

You write the inline assembly using the flavor that you know the best. The code will be generated as per your assembly instruction by the compiler. If there is any error in the assembly, it is user error.

Quoting - Om Sachan (Intel)

The Intel C++ compiler support inline assembly. In Linux platform the compiler by default assumes that you are using the AT &T (GNU style Assembly). You can also use Microsoft style assembly syntax but you need to tell the compiler for the same using option use-masm.

You write the inline assembly using the flavor that you know the best. The code will be generated as per your assembly instruction by the compiler. If there is any error in the assembly, it is user error.

I think you didn't understood the queries asked.

I had asked ""Does Intel has some table for instructions conversion of GNU-style Assembly (GAS/AT&T) to Intel Assembly(NASM)?

Example: Conversion of MOV(GAS syntax) instructions - movq, movslq, movss, movsd, movntq, movntdq, etc. in Intel-syntax(NASM).

To be more informative, simply check the below .S content when using "-use-msasm" on Linux x86_64 and specially the MOV (movslq, movss, movsd, etc.) instructions -

--
.section .text
.LNDBG_TX:
# -- Machine type EFI2
# mark_description "Intel C++ Compiler Professional for applications running on Intel 64, Version 11.0 Build 20081105 %"
;
# mark_description "s";
# mark_description "-fno-builtin -g -O3 -use-msasm -S";
.file "hello.cc"
.text
..TXTST0:
# -- Begin _Z7t
# mark_begin;
..
..
..LN1:

movq %rdi, %r9 #62.1
movq %rdx, %r8 #62.1
movslq %ecx, %r10 #62.1
..LN3:
.loc 1 71
xorl %edi, %edi #71.10
....
..LN5:
testq %r10, %r10 #71.22
jle ..B1.12 # Prob 10% #71.22
# LOE rax rdx rcx rbx rbp rsi rdi r8 r9 r10 r12 r13 r14 r15
..B1.2: # Preds ..B1.1

movq %r10, 48(%rsp)
movq %rdx, 56(%rsp)

.LN7:
.loc 1 72
movsd 208(%rsp,%r12,8), %xmm0 #72.30
movsd _2il0floatpacket.1(%rip), %xmm1 #72.30
call fmod #72.30
# LOE rbx rbp r12 r13 r14 r15 xmm0
..B1.15: # Preds ..B1.3

movsd %xmm0, 80(%rsp) #72.30
# LOE rbx rbp r12 r13 r14 r15
..B1.4: # Preds ..B1.15
..LN9:
movsd 80(%rsp), %xmm0 #72.15
call sin #72.15
# LOE rbx rbp r12 r13 r14 r15 xmm0
..B1.16: # Preds ..B1.4

movaps %xmm0, %xmm9 #72.15
# LOE rbx rbp r12 r13 r14 r15 xmm9
....
..
movss (%rbx,%r15), %xmm7 #84.30
cvtps2pd %xmm7, %xmm13 #84.30
..LN19:
.loc 1 87
movss 4(%rbx,%r15), %xmm4 #87.30
..LN21:
.loc 1 90
...
...
--

(a) Now, what should be the correct syntax of these MOV inst.(movslq, movss, movsd, etc.) when replacing above MOV as in GNU-style(GAS) into Intel-syntax(NASM)?

(b) Also, w/o using "-use-msasm" FLAG, I get the same GNU-style(GAS) syntax instructions, but I think either above (a) or (b) should have an effect in using "-use-msasm" FLAG for output .S asm, but unfortutanetly I don't see any difference in using "-use-msasm" in .S asm output file?

Note: Above .S asm some section where MOV is been used has been demonstarted here to understand which is a part of .S asm code.

~BR

I do not know of any Intel GAS/AT&T assembly to Intel Assembly mapping table or document. You might be able to find such information on the web. Here are some references that might help:
http://www.chemie.fu-berlin.de/chemnet/use/info/gas/gas_13.html#SEC172
http://asm.sourceforge.net/articles/linasm.html
http://www.ibm.com/developerworks/library/l-gas-nasm.html

By default the Intel C++ Compiler V11.x for Linux* recognizes BOTH the GAS style and Intel style (AKA Microsoft* MASM style) inline assembly instructions, AND generates ONLY GAS style assembly instructions. The Intel C++ Compiler 10.x for Linux, by default recognizes ONLY the GAS style assembly instructions and generates ONLY the GAS style assembly instructions. If you want the 10.x compiler to recognize (not to generate) Intel style inline assembly, then you need to use the "-use-msasm" compiler option. Note that the above switch tells the compiler to only recognize (not to produce) Intel style inline asm instructions. The compiler will always generate GNU style assembly instruction on Linux by design. The above option is not needed with the 11.x compilers.

$ icc -V
Intel C Intel 64 Compiler Professional for applications running on Intel 64, Version 11.0 Build 20090318 Package ID: l_cproc_p_11.0.083
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

$ cat asm_lin.c
int main()
{
asm ( "mov %eax,%ebx"); # mov eax into ebx register
}
$ cat asm_win.c
int main()
{
__asm { mov ebx, eax } # same instruction as above except that in MASM style
# destination register is on the left.
}
$ cat asm_winlin.c

$ cat asm_linwin.c
int main()
{
__asm { mov ebx, eax };
asm ( "mov %eax,%ebx");
return 0;
}

// icc 11.x recognizes both Intel and GAS style assembly instructions without requiring -use-msasm option
$ icc -c -fasm-blocks asm_lin.c
$ icc -c -fasm-blocks asm_win.c
$ icc -c -fasm-blocks asm_linwin.c

$ icc -V
Intel C Compiler for applications running on Intel 64, Version 10.1 Build 20090203
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

$ icc -c asm_lin.c

// 10.x doesn't recognize MASM style inline asm without the -use-msasm option
$ icc -c asm_win.c
asm_win.c(3): error: expected a "("
__asm { mov ebx, eax }
^

asm_win.c(4): error: expected an asm string
}
^

asm_win.c(4): error: expected a ")"
}
^

asm_win.c(4): error: expected a ";"
}
^

// icc 10.x recognizes MASM style asm if you use -use-msasm option, but only GAS assembly style will be generated
// by design.
$ icc -c -use-msasm asm_win.c
$

On Windows*, the Intel C++ Compiler for Windows* by default recognizes and generates Intel style assembly output (without requiring the -use-msasm" option). If you have inline asm code that you need to compile on both Windows and Linux, you may use the Intel style inline assembly (instead of GAS) in your code and use the -use-msasm switch on Linux (with icc 10.x compiler. Not needed with icc 11.x compiler). You could try to compile your C/CPP code example with the icl compiler on Windows to see the type of Intel asm style instructions generated. The instructions generated will not mirror the ones generated on Linux but may help with recognizing the difference in syntax between the two asm styles.

Quoting - Mark Sabahi (Intel)
I do not know of any Intel GAS/AT&T assembly to Intel Assembly mapping table or document. You might be able to find such information on the web. Here are some references that might help:
http://www.chemie.fu-berlin.de/chemnet/use/info/gas/gas_13.html#SEC172
http://asm.sourceforge.net/articles/linasm.html
http://www.ibm.com/developerworks/library/l-gas-nasm.html

By default the Intel C++ Compiler V11.x for Linux* recognizes BOTH the GAS style and Intel style (AKA Microsoft* MASM style) inline assembly instructions, AND generates ONLY GAS style assembly instructions. The Intel C++ Compiler 10.x for Linux, by default recognizes ONLY the GAS style assembly instructions and generates ONLY the GAS style assembly instructions. If you want the 10.x compiler to recognize (not to generate) Intel style inline assembly, then you need to use the "-use-msasm" compiler option. Note that the above switch tells the compiler to only recognize (not to produce) Intel style inline asm instructions. The compiler will always generate GNU style assembly instruction on Linux by design. The above option is not needed with the 11.x compilers.

$ icc -V
Intel C Intel 64 Compiler Professional for applications running on Intel 64, Version 11.0 Build 20090318 Package ID: l_cproc_p_11.0.083
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

$ cat asm_lin.c
int main()
{
asm ( "mov %eax,%ebx"); # mov eax into ebx register
}
$ cat asm_win.c
int main()
{
__asm { mov ebx, eax } # same instruction as above except that in MASM style
# destination register is on the left.
}
$ cat asm_winlin.c

$ cat asm_linwin.c
int main()
{
__asm { mov ebx, eax };
asm ( "mov %eax,%ebx");
return 0;
}

// icc 11.x recognizes both Intel and GAS style assembly instructions without requiring -use-msasm option
$ icc -c -fasm-blocks asm_lin.c
$ icc -c -fasm-blocks asm_win.c
$ icc -c -fasm-blocks asm_linwin.c

$ icc -V
Intel C Compiler for applications running on Intel 64, Version 10.1 Build 20090203
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

$ icc -c asm_lin.c

// 10.x doesn't recognize MASM style inline asm without the -use-msasm option
$ icc -c asm_win.c
asm_win.c(3): error: expected a "("
__asm { mov ebx, eax }
^

asm_win.c(4): error: expected an asm string
}
^

asm_win.c(4): error: expected a ")"
}
^

asm_win.c(4): error: expected a ";"
}
^

// icc 10.x recognizes MASM style asm if you use -use-msasm option, but only GAS assembly style will be generated
// by design.
$ icc -c -use-msasm asm_win.c
$

On Windows*, the Intel C++ Compiler for Windows* by default recognizes and generates Intel style assembly output (without requiring the -use-msasm" option). If you have inline asm code that you need to compile on both Windows and Linux, you may use the Intel style inline assembly (instead of GAS) in your code and use the -use-msasm switch on Linux (with icc 10.x compiler. Not needed with icc 11.x compiler). You could try to compile your C/CPP code example with the icl compiler on Windows to see the type of Intel asm style instructions generated. The instructions generated will not mirror the ones generated on Linux but may help with recognizing the difference in syntax between the two asm styles.

Hello Mark,

Thanks for your explanation, I am totally convinced with your examples and explanation demonstrated. I had gone through all above links as suggested by you.

Somehow, my section of code generates MOV instructions like - movslq, movss & movsd in GNU-style syntax (GAS) as an output on Linux x86_64 using ICC-v11.0. I am not sure what could be the equivalent replacementof movslq, movss & movsd while writing Inline using Intel-syntax (NASM). But in google(alt.lang.asm) I read that the equivalent of "movslq" of GNU-style syntax(GAS) is "movsx" in Intel-syntax(NASM) but using this with proper format of Intel-syntax I am getting errors.

Since, my section of code of C/C++ application is big, I can't share it. Could you write a test case where the ICC-v11.0 on Linux x86_64 generates MOV instructions like - movslq, movss, movsd, movntq in its .S file and then represent these set of MOV instructions as an Inline-asm in Intel-syntax(NASM) with proper format, compile with ICC-v11.0 on Linux-x86_64 and see what messages if any you are getting. If sucessful, please share with me.

Looking for such test case and help.

~BR

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen