How to inline x64 asm in vs2017 ?
 

Hi
Can I use inline x64 asm in vs 2017 ?
When I use inline asm in x64 , this error show up :

nonstandard extension used: '__asm' keyword not supported on this architecture

There is no x64 inline assembly with the Microsoft compiler.

http://masm32.com/board/index.php?topic=4211.0

maybe useful in check options.

You have several options.
1. Switch to some other compiler like intel or GCC. You can still use Visual Studio, just a different compiler, they don't have inline asm restrictions.
2. Compile a separate .asm and link with other compiled .cpp files. This can be configured, so it's done automatically when the solution is built.
3. Sometimes it's enough to use intrinsics. But of course they don't cover all asm instructions.

@Archer
I am trying to use GCC x64

Or as a fourth option since it has yet to be mentioned, write a tool which at compile time extracts all inline code from C modules intended for x64 compilation, put them in an .asm file with some type of label or function definition, compile them, replace the C code with an appropriate control flow transfer, and so forth.

Unfortunately, nothing will be exactly equivalent mentioned so far in MSVC as the control flow transfer is pretty hard to avoid.

Best yet might be to keep requesting MS to make the long overdo change as a developer feedback or feature request.

Two ways:

- Intrinsics https://msdn.microsoft.com/en-us/library/26td21ds.aspx
- As above suggested, .asm linking here a tutorial on how to setup VS + MASM

http://lallouslab.net/2016/01/11/introduction-to-writing-x64-assembly-in-visual-studio/

Best Regards,
Evilcry

But since you are not linking the .asm inline, there are excessive call or jump statements emitted. The best would be if MS were to add it.

Does one call or jump really matter?
I mean, if you said you couldn't easily access local variables or structures, I'd agree... but "excessive call", it sounds like you are trying to optimize something. In that case inline assembler is hardly any good - it's a blackbox for the compiler (at least for the Microsoft's) so it has to dump the values from registers into local variables and after the inline assembly load them back. In other words, a piece of inline assembly heavily breaks the optimization of the surrounding C code - so it's usually not worth it, it does more damage than one call would (so it's better to write the whole CPU intensive piece of code in assembler as a separate function).

It matters because its very convenient to program like this. By having to call/return or jump/jump or what have you (also don't forget all the stack setup and cleanup), it forces calling conventions and requires the parameters to be dealt with and such. Yes the MS implementation is not as clever as in GCC/GAS where you can really customize details of the behavior. I agree for optimization its a lame point as you would better be off with pure asm or optimized C rather than a mix and match without sophisticated inline-ing support.

Further its easier to write portable 64/32 bit code without calling conventions and clever use of macros, as the calling conventions are so different you have to use different assembly instructions (registers vs stack).

A C function can modify itself in memory also using clever tricks with inline assembler which has its obfuscation or other uses.

But I suppose this discussion is easily already documented: So optimization is on the list after all :D

While you can't use inline asm, you can link ASM files into your program and use a separate compiler such as MASM to build .asm files with your project. Visual Studio has support for this built-in.

If you absolutely need inline asm you can use a different compiler/linker.

Well it looks like it will not happen anytime either. Unless we all get together to vote it to the top. Difficult to reason about proving correctness in the compiler I suppose :D

Just create a .ASM file, change the build rule to MASM, define the subroutine and call it from the C file.


masm.asm
file.c

@avalon
Typo...

ChangeRaxRoutine PROC
mov rax, 0x4141
ChangeRcxRoutine ENDP

....
.code

public ChangeRaxRoutine

ChangeRaxRoutine proc
mov rax, 04141h
ChangeRaxRoutine endp
end

Just an example, hope can help you: https://github.com/vic4key/MS-Mix-Cpp-n-Asm-in-64-bit

@vic4key
To avoid the application crash you need to allocate/align the stack...
Compiled and tested (MSVC 2017 15.7.3)

Hi Insid3Code. Not used any local variables inside. So the allocation is unnecessary I think. Even it can be shorter. Eg.

F1 PROC
PUSHAD
LEA RCX, TXT_F1
CALL puts
POPAD
F1 ENDP

More, your edited code should be:

F1 PROC
PUSH RBP
MOV RBP, RSP
SUB RSP, 40 ; Allocate space on the stack (8 for alignment and 32 for shadow space); Below of MOV RBP, RSP, this instruction already saved RSP to RBP.
LEA RCX, TXT_F1
CALL puts
LEAVE
ADD RSP, 40 ; Cleanup the stack... ; Not needed. The LEAVE instruction did it.
RET
F1 ENDP

Hi Vic,
Are you already tested your snippets ?
Attached, both snippets (allocate/align) and binaries (one crash the other works fine)

I don't know if you can download the attachment from this topic, here external link:
Compiled and tested (MSVC 2017 15.7.3)

leave is short for
mov rsp, rbp
pop rbp
lose "add rsp, ..."

This discussion is majorly lacking a hugely important point:
Calling convention in x64 always uses the RCX, RDX, R8, R9 registers for passing the first 4 arguments (anything up to 64 bit values or pointers), while additionally to those 4 registers, RAX, R10 and R11 are considered volatile. The return value is in the RAX or possibly for a 128-bit return value would be in the RAX:RDX.

This is opposed to x86 where the prior scheme is closest to fastcall which used the ECX and EDX for argument passing before resorting to the stack with additionally the EAX volatile. However in cdecl (caller clean-up stack) calling convention, arguments are all passed on the stack, EAX, ECX and EDX are considered volatile, and the return value in EAX or EAX:EDX. syscall is the same except without the 3 registers being considered volatile. stdcall is also almost the same except the callee cleans up the stack.

If mixing C with external asm, it would be extremely wise to be familiar with all these details.

For more details which are too lengthly to include, refer to:

Microsoft x64 calling convention

Therefore code given here is all non-standards compliant with arbitrary calling convention (compiler will have return address of 8 bytes so an extra 8 indeed is needed but if called from assembler directly, etc assumption may not hold). If not calling back into C code which has been externed for use by the asm code (like puts is for sure), this should obviously not be necessary - neither alignment or shadow space.

That pattern is needed for both F1 and F2 and its straightforward.

Yes, right. In x64 arch, we always need to allocate the space for which called "shadow space". So, the above code should be:

Thank you, guys.

It should be:

You normally don't align stack like that.
You know that the caller has (according to the calling convention) taken care of its stack alignment and therefore the RSP on entry ends by 8 (the stack was 16B aligned before and then the return address has been pushed there by the CALL).
So the initial PUSH RBP has aligned the stack to 16B again, SUB RSP, 32 didn't break the alignment - and the AND instruction is useless, RSP is already aligned there.

I have to say thank you to all of you guys thank you for your solutions I learned a lot of things. :)

If your asm function is designed to be called from C only then yes I suppose that is a fair assumption. But in fact if it is called from asm including your own or I suppose unknown callers, then it is a false assumption. And this code is known.

The extra 8 bytes comes from having called your own function within proper convention asm already or the return address in case of Windows ABI invocation. CALL F1 in an improperly aligned routine of course adds 8 bytes to the stack and then adding 8 again would misalign it (hence the code examples leaked out there and above which show 40 byte assuming misalignment by an internal call already from ASM despite not having this in examples). The safest assumption is to assume any caller, and realign the stack with an AND RSP, -16 or even to just do it on just the lower 32-bit ESP.

Linux has the same issue even with 32-bit code for late GCC versions as seen in this discussion: Calling printf in extended inline ASM
Even better here is a book on the issue for more in depth detail though unfortunately not listing the generic solution and instead letting you make assumptions or track things: