Introduction to x64 Assembly

Some reasons to use intrinsics:
* Inline asm not supported in x64.

Works fine in GCC. You can use $eax or $rax to reference $rax. Also the Microsoft 64-bit calling convention works with MinGW GCC since 4.4.

AMD has a similar guide on x86-64, and it said things like not to use loops for short iterations because the compiler likely won't always optimise in 64-bit mode for these. So 'unroll' them. GCC has options: -funroll-all-loops -funroll-loops . It's not hugely noticeable when you have a quad-core machine @ 3.4 GHz. The guide from AMD is very technical but does explain some basics like that RAX is basicallly EAX and that a __stdcall (if that were used on x86-64 Windows) is not ordered EAX,EDX,EDI (with return value in EAX) but now it's RAX,RSI,RDI if I remember correctly. I was having trouble putting inline ASM into an app just to see if it would work, and then realised GCC won't convert it to x86-64 for me. PUSH EAX worked but almost nothing else did.

It'll be some time before the Windows world fully moves to 64-bit, but there will certainly be reversing when that time comes. By contrast, most software for Linux can either be compiled for 64-bit or has a 64-bit version binary (including things like Maya).

Originally Posted by Taitch

Some reasons to use intrinsics:
* Inline asm not supported in x64.

this is one pice of crap for someone developing low level stuff with c++&asm

all the code should be rewrited in order to compile for x64

[Fyyre]

inline assembly language in functions? not really so useful, imho... for situations where it is, intrincs do well enough (imho, of course :)

i.e.

#define memopen()   _disable(); __writecr0(__readcr0() & (~(0x10000)));
#define memclose()  __writecr0(__readcr0() ^ 0x10000);  _enable();

atm... 60% of code I write is for nt kernel (x64).

-fyyre

Originally Posted by unknownone

this is one pice of crap for someone developing low level stuff with c++&asm

all the code should be rewrited in order to compile for x64 :(