Exetools

Exetools (https://forum.exetools.com/index.php)
-   x64 OS (https://forum.exetools.com/forumdisplay.php?f=44)
-   -   X64 inline asm (https://forum.exetools.com/showthread.php?t=12730)

Fyyre 04-08-2010 07:28

X64 inline asm
 
Hi all,

I discovered this for myself recently, and wanted to share. If this is already well known, disregard =)

The Intel C/C++ compiler add-on for Visual Studio will allow you to still use inline assembly language on the X64 platform. The syntax and such is close enough to MSVC that modifications needed to code to compile existing code with the Intel compiler are minimal at best, IMO.

-Fyyre

winndy 04-08-2010 17:13

where can I download "Intel C/C++ compiler add-on for Visual Studio "?

Av0id 04-08-2010 17:59

on vdown for example

Fyyre 04-08-2010 22:44

Quote:

Originally Posted by winndy (Post 67561)
where can I download "Intel C/C++ compiler add-on for Visual Studio "?

I recommend downloading it straight from Intel's site http://software.intel.com/en-us/arti...uation-center/ then use any TBE Intel.lic to activate it during the installation ;) Can PM me if you need one.

-Fyyre

jump 04-08-2010 23:10

Quote:

Originally Posted by Fyyre (Post 67554)
Hi all,

I discovered this for myself recently, and wanted to share. If this is already well known, disregard =)

The Intel C/C++ compiler add-on for Visual Studio will allow you to still use inline assembly language on the X64 platform. The syntax and such is close enough to MSVC that modifications needed to code to compile existing code with the Intel compiler are minimal at best, IMO.

-Fyyre

Very interesting news. I have read everywhere that inline assmbler isnt possible on x64 architecture.
Could you show us correct syntax for inline assembler which will Intel C++ Compiler accept ?

--
Jump

Archer 04-09-2010 00:43

Inline asm is forbidden in studio compiler only. Guess they are too lazy to implement it. GCC and intel support it just fine.

Fyyre 04-09-2010 10:56

Quote:

Originally Posted by jump (Post 67570)
Very interesting news. I have read everywhere that inline assmbler isnt possible on x64 architecture.
Could you show us correct syntax for inline assembler which will Intel C++ Compiler accept ?

--
Jump

It is virtually the same as MSVC:

__asm mov rbx, rax;

or

__asm
{
...
}

emit format is:

__asm __emit 0xCC;

sample function:

Code:

__declspec(naked) int __fastcall strcmpW(const wchar_t *s1, const wchar_t *s2)
{
        __asm {
        push rdi
        push rsi
        mov rdi, rdx
        mov rsi, rcx
        or rcx, -1
        xor rax, rax
        repne scasw
        not rcx
        mov rdi, rdx
        repe cmpsw
        xor rdx, rdx
        mov ax, [rsi - 2]
        mov dx, [rdi - 2]
        sub rax, rdx
        pop rsi
        pop rdi
        ret
        }
}


jump 04-09-2010 16:08

So if i understand correct, the inline assmbler have to be also x64 not x86,right?
So you cant tak source with inline x86 assembler and think it will be compileable for x64 architecture. You have to rewrite it, right?

--
Jump

Git 04-09-2010 18:45

I think if you are proposing to write a full function in asm as opposed to a small piece of inline code, then you have to be very careful with the prolog and epilog, and especially careful with the structured exception handling. In providing inline asm, Intel assume you are fully conversant with X64.

Git

Av0id 04-09-2010 20:39

Quote:

So if i understand correct, the inline assmbler have to be also x64 not x86,right?
intel compiler supports both x86 and x64 assembler code

Fyyre 04-11-2010 15:32

x86 or x64 depends upon your project (like Av0id said above).

Regarding re-writing of code, how big of task depends on the code itself...

i.e. the above strcmpW function, he only require change of registers from e*x to r*x....

AFAIK the calling covention always __fastcall on X64, more simple than x86 assembly, imo.

-Fyyre

Quote:

Originally Posted by jump (Post 67583)
So if i understand correct, the inline assmbler have to be also x64 not x86,right?
So you cant tak source with inline x86 assembler and think it will be compileable for x64 architecture. You have to rewrite it, right?
Jump


Git 04-11-2010 18:38

There's some good info on MSDN.

Calling convention
Parameter passing
Exception handling

The exception handling page has a link to MASM macros for Prolog and Epilog.

THE site for driver writers, OSR, has some info too. There is good info there in all the subtopics on exception handling, prolog & epilog, stack usagae, etc.

Git

gigaman 04-17-2010 17:13

For the inline assembler, keep in mind that it heavily "corrupts" the optimization of the surrounding C code (well, at least it always did for MSVC, donno about Intel, but would guess it's the same). When the compiler reaches the asm block, it's a "black box" for it... so it dumps all the register values into local variables, appends the assembler block... and then loads the register values back.
So, it's better to write the whole function in inline assembler - than just a part, in which case the result might be worse than keeping it all in C, because the rest of the function is optimized much worse than if it were all in C.

It would be interesting to know what led Microsoft to bad inline assembler in x64...

Git 04-17-2010 18:18

I agree gigaman. It even more true when you consider the difficulty in writing a true x64 full function properly.

Git

gigaman 04-21-2010 04:37

Well, I probably shouldn't have written "whole function"... let's say the whole block of code where the performance is of interest.
Sure, you may do basic parameter checking in C, allocate the local variables... and then use the inline asm to do the real job. So, you don't have to worry about stack allocation, you have access to fields of C structures... and x64 asm is basically the same as x86, so I wouldn't call it difficult ;)

Git 04-21-2010 17:29

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 04-22-2010 21:31

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.

Code:

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 04-23-2010 00:52

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 04-29-2010 18:15

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

Fyyre 04-29-2010 23:19

Quote:

Originally Posted by jgutierrez (Post 67950)
I thought that inline x64 ASM was implemented in latest Intel C++ compiler (11.1 I guess).

11.1 is what I use.

Git 04-30-2010 18:55

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 06-21-2010 10:16

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 06-22-2010 20:44

1b. As
Code:

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

Quote:

Originally Posted by matt (Post 68527)
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.


pLayAr 07-12-2010 18:23

it seems that vc do not support x64 inline asm?

Git 07-12-2010 18:28

NO IT DOES NOT

matt 07-23-2010 07:39

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

Quote:

Originally Posted by Fyyre (Post 68539)
....
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.

Quote:

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

Zaltekk 07-28-2010 07:50

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 07-30-2010 18:18

Quote:

Originally Posted by Git (Post 68739)
NO IT DOES NOT

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

Git 07-30-2010 19:04

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 08-04-2010 17:37

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

_ruzmaz_ 08-09-2010 07:54

hiew 8.x has x64 assembler

pLayAr 03-08-2011 17:48

we can use .asm file with custom build in vc to support x64 asm

RaptorFactor 05-17-2011 21:32

Sorry to bump such an old thread, but another alternative to using a different compiler or linking in .asm files is to use a library such as AsmJit* (it's what I use to dynamically generate code stubs for things like robust DLL injection, remote export calling, etc etc).

Obviously there is more overhead as you need to 'JIT' the function, but this is a one-off cost, and if you're worried about using the code in performance critical areas of your code you can simply JIT all your functions at startup and cache them rather than on-demand.

* AsmJit project page: https://code.google.com/p/asmjit/

Pansemuckl 05-26-2011 08:52

Quote:

Originally Posted by pLayAr (Post 71874)
we can use .asm file with custom build in vc to support x64 asm


How can you explain?

ArC 06-13-2011 22:28

Quote:

Originally Posted by Pansemuckl
How can you explain?

In VS2010, compiling *.asm files is provided out of the box but I think you need to enable it explicitly for each project. To do so, load your project and choose Project->Build Customizations and enable the entry masm. Now, any *.asm file in your project is configured to to be compiled with MASM (except for those which have their item type explicitly set I suppose).

AFAIK this feature is not present in older versions of VS and you need to specify a custom build step to compile *.asm files. To do so add your *.asm files to your project, right click them and select Properties. The Item Type property should show Does not participate in build. Change this to Custom Build Tool and hit Apply. A new category should appear in the properties tree which allows you to specify the command line to run, message to print to build log, what files it outputs etc. For building *.asm files the Command Line and Outputs should look like that:
Code:

Command Line: ml /c /Fo"$(IntDir)%(Filename).obj" "%(FullPath)"
Outputs: "$(IntDir)%(Filename).obj"

You may want to adjust the command line a bit, e.g. to have debug info generated, but appart from that *.asm files should compile now.

infern0 10-30-2011 21:34

is anybody succeed with using intel compiler in VS2010 ?

rox 10-31-2011 23:44

Quote:

Originally Posted by infern0 (Post 75600)
is anybody succeed with using intel compiler in VS2010 ?

its plug&play type software, you can hardly fail.. just after installing compiler right click your project and select something like 'use intel compiler blah blah blah'

dbcch 11-14-2011 11:07

Does anyone have any empirical or measured benchmarks on how well the Intel C/C++ compiler does vs Microsoft's? Aside from the X64 inline assembly support, I'm just wondering if there is a compelling reason to switch. It would seem it is likely to generate optimal code, but is the code generated tuned for Intel processors? Hmm...

Quote:

Originally Posted by rox (Post 75612)
its plug&play type software, you can hardly fail.. just after installing compiler right click your project and select something like 'use intel compiler blah blah blah'

Agreed, WTF... how could you fail? ;p

Quote:

Originally Posted by gigaman (Post 67801)
For the inline assembler, keep in mind that it heavily "corrupts" the optimization of the surrounding C code (well, at least it always did for MSVC, donno about Intel, but would guess it's the same). When the compiler reaches the asm block, it's a "black box" for it... so it dumps all the register values into local variables, appends the assembler block... and then loads the register values back.
So, it's better to write the whole function in inline assembler - than just a part, in which case the result might be worse than keeping it all in C, because the rest of the function is optimized much worse than if it were all in C.

AMEN Brother! Besides incurring overhead when injected into the middle of a function, people need to remember it mucks with the compiler's optimization in general. As processors become more complex, it frankly takes a 'smart' compiler to generate optimal code. Therefore, you must be very careful about using inline asm. Use it only when you absolutely have to, basically. Any extraneous use and you risk doing more harm than good.

Quote:

Originally Posted by gigaman (Post 67801)
It would be interesting to know what led Microsoft to bad inline assembler in x64...

I believe it is because of your aforementioend issue, though who knows for sure. I believe they want to discourage any inline assembly, of any type, and took the chance to not add this feature.

JMI 11-14-2011 19:18

dbcch:

It appears you turned what should easily have been one post into three, which makes it appear like attempting to just increase your post count. I have combined them into one post, rather than just deleting them. ;)

Regards,

dbcch 11-15-2011 13:06

.... Ok, thanks. I see what you mean now, that 25 post to get to downloads stuff. I don't want downloads, so you can cancel me from downloads forever as opposed to treating my posts as part of any scheme.


All times are GMT +8. The time now is 06:53.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2022, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX