Exetools

Exetools (https://forum.exetools.com/index.php)
-   x64 OS (https://forum.exetools.com/forumdisplay.php?f=44)
-   -   Introduction to x64 Assembly (https://forum.exetools.com/showthread.php?t=12977)

Git 09-10-2010 18:15

Introduction to x64 Assembly
 
Very useful new article by Intel :

Introduction to x64 Assembly

Git

Taitch 09-13-2010 23:03

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).

unknownone 12-25-2010 06:15

Quote:

Originally Posted by Taitch (Post 69461)
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 12-30-2010 07:25

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

i.e.

Code:

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

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

-fyyre

Quote:

Originally Posted by unknownone (Post 70795)
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 :(


deroko 12-31-2010 23:21

Well I would love to have those inline asm markers in the code :) I've tried to use instrinsic to achive same but during optimization, my macros are gone, mixed with other instructions when optimized :) and officially I hate to use imports as markers, as it adds extra work on my side which by default wouldn't be needed. (eg. walk import table, and remove IID which points to my fake_import_marker.dll), and also there is always chance that searching for call dword ptr[mymarker_start] can lead to wrong data, and wrong analyse

However everybody should know whom are developing using asm on x64 that you must keep stack always 16 byte aligned, as some sse instructions require memory to be 16 byte aligned when data is written to memory, otherwise you will get exception. I learnt this in hard way, after 1h debugging why application crashed when writing to existing and r/w memory from some API call (don't even remember what API this was)

tHE mUTABLE 01-01-2011 21:49

@deroko. Have you tried to disable compiler optimizations selectively? (I've been into a similar situation :) ) Most of the compilers I'm aware of support this feature via a "#pragma". Intel compiler provides a lot of fine-grained options for enabling/disabling specific optimizing transformation.

Hope that helps!

deroko 01-01-2011 23:40

Well, disabling optimization is not an option, unfortunately. There are pragmas in msvc to disable/enable optimization but those are global. eg. can't put them before macro, and after macro. For now I think I will stick with import table trick until ms adds this option again, or use /Od for a while :)

tHE mUTABLE 01-02-2011 00:47

Could you please try the following (enable/disable global optimization at the function/macro level). I'm not sure about macro but theoretically it should definitely work.

#pragma optimize( "g", off )
// Macro goes here
#pragma optimize( "g", on )

Another option would be to enable optimization profiling, (MSVC has one of the worst optimization profiler I've ever seen!) so that you can pinpoint the specific transformation that is getting exercised by the compiler, then you can selectively disable or at least tweak that optimization accordingly which is I'm guessing it's most likely to be inlining!

deroko 01-02-2011 01:34

That's the one I was referring, it can be only set globally, not possible to set inside of a function :)

Git 01-02-2011 20:22

Or you could use the Intel compiler.

Git

Fyyre 01-03-2011 03:55

Quote:

Originally Posted by deroko (Post 70913)
That's the one I was referring, it can be only set globally, not possible to set inside of a function :)

optimization can set on function to function basis, but not within the function itself. i am thinking you mean this by "globally" ?

i.e.

Code:

#pragma optimize( "", off )

void meow()
{
  /* ... */
}

#pragma optimize( "", on )

Intel-specific Pragma Reference

-Fyyre

deroko 01-03-2011 17:48

This is globally, as it affects whole function, not only a portion where macro would be stored. Well it doesn't really matter, as I've already worked this import thing long time ago. I'm just saying why inline asm would be nice to have in msvc x64 compiler :)


All times are GMT +8. The time now is 19:42.

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