X64 inline asm

[Git]

Agreed, that is the way to do a whole function, but then you have to ask yourself if you really can do a better job that the optimiser or you may as well take the easy route and do the whole function in C.

Git

[rox]

just so you know - MS did not implement inline asm in x64 because it is 'unsafe'. apparently they are very concerned about noobs who have no clue what they are doing. they did same with default values for methods in c# - no such thing there because 'it might confuse programmer'.

regarding inline asm 'black box' theory - is all crap. i made a testcase just to see this, because it even sounds so much unreasonable.

00FD1045  sub         edi,1 
	while(i != 0)
00FD1048  jne         main+22h (0FD1022h) 
	}

	__asm xor ebx, ebx	// should be restored after asm block
00FD104A  xor         ebx,ebx 

	char naughtyNumber[255];
	itoa(a + b, naughtyNumber, 16);
00FD104C  push        10h  
00FD104E  lea         eax,[esp+10h] 
00FD1052  push        eax  
00FD1053  add         esi,ecx 
00FD1055  push        esi  
00FD1056  call        _itoa (0FD7258h) 
00FD105B  add         esp,0Ch

as you see i xored ebx and compiler has no intention to restore it. now maybe i am missing something.. but ebx is non-volatile register - if msvc compiler really did 'black box' tricks then register should be restored.

[Fyyre]

AFAIK, EBX is the one register not used in most WINAPI functions.

M$ like when programmers do things 'their way' ... whether or not they have valid reason is subject of debate, I think =)

Removing inline assembly from x64 just made a pain in the ass. Just like how they not document many ntapi functions... leaving the reverser/programmer to spend much time looking finding their hidden known.

-Fyyre

[jgutierrez]

I thought that inline x64 ASM was implemented in latest Intel C++ compiler (11.1 I guess).

[Fyyre]

Originally Posted by jgutierrez

I thought that inline x64 ASM was implemented in latest Intel C++ compiler (11.1 I guess).

11.1 is what I use.

[Git]

That is exactly where the thread started. The point is that MS removed the x64 inline assembler from visual studio, but Intel included it in their compiler.

Git

[matt]

The issue with inline asm is you have to implement differnet set for different arch: i386, x86_64, IA64 etc. The only motivation for me, is using "lock", since VS lacks of support.

Anyone is familiar with Intel c compiler for Windows ? I want to confirm whehter intel c compiler supports these items:

1, structure designated initializers
Three formats are widely used, especially the 1st:
a) struct test {int i, j, k, l;} a = {.l = 60, .i = 10};
b) int array[8] = {[0] = 10, [5] = 60}; /* only initialize the
1st and 5th members */
c) struct test {int i, j, k, l;} a = {l = 60, i = 10};

2, macros to return a value

Complex macroes need "({ ... )}" style to return a value, eg:
1) #define min(X, Y) ({ typeof (X) x_ = (X); typeof (Y) y_ = (Y); \
(x_ < y_) ? x_ : y_; })
2) #define my_macro(cond, p1) ({while (cond) {rc = func(p1);}; rc;})
WDK compiler only supports "()" or "{}" styles. the former can carry
a return value but with limitations; the latter can not return a value
to its caller.
3, typeof

I'd like to replace MS compiler of WinDDK if intel compiler supports these features.

[Fyyre]

1b. As

int array[8] = {array[0] = 10, array[5] = 60};

Both macros, yes.

Somethings will require slight adjusting. I too use the Intel Compiler for driver building, from inside of Visual Studio 2008.

-Fyyre

Originally Posted by matt

The issue with inline asm is you have to implement differnet set for different arch: i386, x86_64, IA64 etc. The only motivation for me, is using "lock", since VS lacks of support.

Anyone is familiar with Intel c compiler for Windows ? I want to confirm whehter intel c compiler supports these items:

1, structure designated initializers
Three formats are widely used, especially the 1st:
a) struct test {int i, j, k, l;} a = {.l = 60, .i = 10};
b) int array[8] = {[0] = 10, [5] = 60}; /* only initialize the
1st and 5th members */
c) struct test {int i, j, k, l;} a = {l = 60, i = 10};

2, macros to return a value

Complex macroes need "({ ... )}" style to return a value, eg:
1) #define min(X, Y) ({ typeof (X) x_ = (X); typeof (Y) y_ = (Y); \
(x_ < y_) ? x_ : y_; })
2) #define my_macro(cond, p1) ({while (cond) {rc = func(p1);}; rc;})
WDK compiler only supports "()" or "{}" styles. the former can carry
a return value but with limitations; the latter can not return a value
to its caller.
3, typeof

I'd like to replace MS compiler of WinDDK if intel compiler supports these features.

it seems that vc do not support x64 inline asm?

[Git]

NO IT DOES NOT

[matt]

Thanks, Fyyre! What version of intel C compiler are you using ? And what icl options did you specify when compiling ?

Originally Posted by Fyyre

....
Both macros, yes.

I gave it a try with Intel(R) C++ Compiler Professional 11.1.065 (evaluation)
with option /Qc99 (to enable c99 support).

But icl failed to compile the macros. "({})" style macro isn't supported. typeof neither.

Somethings will require slight adjusting. I too use the Intel Compiler for driver building, from inside of Visual Studio 2008.

Two types of the 3 structure initializers are supported.That solves lots issues, anyway.

-Fyyre

Thank you,
Matt

The Intel C++ Compiler also has less C++0x support than the latest GCC and MSVC compilers. Also note that you nee MSVC(earlier than 2010) installed to use the Intel compiler on Windows. Even if you don't plan to use Visual Studio integration. It depends on some of the command-line tools and the includes/libraries.

I believe that 11.1 was released in 2009, so hopefully they will release a new version sometime soon that can at least integrate with the new Visual Studio. The C++0x part might not seen too important, but the problem I ran into with it was not being able to use recent GCC headers for TR1 due to the implementations being updated to make use of C++0x features. It isn't fun to lack access to std::tr1::shared_ptr.

I haven't tested the Intel compiler with VS2008 yet as I lost my installation DVD. I _think_ it got TR1 support in a feature pack, but I'm not positive. If it did, I do not know if it makes use of C++0x features that the Intel compiler is missing. Maybe someone else can comment on this aspect.

One last thought: I'm not sure how boost implements shared_ptr, but it is likely very similar to how the new GCC headers implement it. There is a chance, however, that it would compile with the Intel compiler. Myabe someone else can comment on this too.

[wishi]

Originally Posted by Git

NO IT DOES NOT

Sure? There must be some way... Sounds like I want ICC from now on. Interesting thread.

[Git]

Yes, I am quite sure that VS compiler does not assemble X64 machine mnemonics. The Intel compiler does apparently and I have very high opinion of the Intel compiler, but be very very careful that you learn all the ramifications of using assembler on X64, especially if you want to write whole procedures. The Epilog/Prolog stuff and SEH is much more involved than the 32bit world.

Git

[Nooby]

little bit offtopic: does anyone know any single line assember(like the one in olly's disasm) that supports X64?