__asm keyword

[shadowx360]

Not too long ago, I decided to learn High Level Assembler in order to write programs where great speed is needed. Needless to say, I miss using all the high level API's and functions C++ offers. I just found out that it is possible to integrate asm into C++, so I can have my speed when I need it, and still be able to use C++.

However, The MSDN article regarding the keyword __asm doesn't specify which of asm, and HLA is not accepted. Does anyone know what form of asm I should learn in order to use it with the __asm keyword? I think it might be MASM, but I'm not sure, I don't want to learn another asm language and not be able to use it.

[dc_2000]

I'm not sure how exactly you call it, but a sample of the use of the __asm keyword could be this:

DWORD buffer[10];

_asm{
		push		ecx
		push		ebx
		mov		ecx, 10
		lea		ebx, [buffer]
lbl_repeat:
		mov		DWORD PTR [ebx], 0
		add		ebx, 4
		dec		ecx
		jnz		lbl_repeat
		pop		ebx
		pop		ecx
}

But here's the word of advice: BE VERY CAREFUL when using assembler commands in your C++ code. Here's the reasons why:

1. It is very hard to debug the assember code, as well as follow the logic in the source file (see the sample above, is it evident that I'm clearing the 'buffer' array?)

2. By combining a linker generated machine code with the one you add using the __asm keyword you can easily run into trouble by not saving certain registers or contents of the stack.

3. It is very easy to mess up the stack (by forgetting to call 'pop' or using too many 'push' ops) which will result in the most certain crash of your app.

4. Even though you think that you will do a better job by using a direct assembler code, this is not always the case. All of the modern compilers can optimize your code for a specific Operating System and the type of a CPU. Recompiling your C++ source code to match a certain optimization settings is as quick as changing the Visual Studio project settings. Doing this with a raw asm is VERY complicated.

5. There are so many nuances that apply to the machine code (in perspective of the current multi-core CPUs supporting various forms of optimization, such as hyperthreading, registry and op-code cache, etc.) that you cannot possibly optimize your code by writing it in asm manually.

Here's a quick example. The asm code below:

lbl_repeat:
		mov		ecx, DWORD PTR [edx]
		add		edx, 4
		add		edi, 1
		add		ecx, edi
		mov		DWORD PTR [ebx], ecx
		add		ebx, 4
		cmp		ecx, 0
		jnz		lbl_repeat

will work several CPU cycles slower than this code:

lbl_repeat:
		mov		ecx, DWORD PTR [edx]
		inc		edi
		add		edx, 4
		add		ecx, edi
		mov		DWORD PTR [ebx], ecx
		and		ecx, ecx
		lea		ebx, [ebx + 4]
		jnz		lbl_repeat

6. Lack of support for preprocessor commands in the __asm code block.

Example:

int v = 0;
//The following ASM will produce an error
__asm
{
mov	eax, sizeof(v)
}

So these are just some nuances you have to consider before plunging into the world of the x86 assembler. If I were you (and if you're not the guy who actually designs x86 compilers) I'd let Visual Studio do all the assembler translation and you worry about the C++ logic.

[CBasicNet]

If you code carefully in C++, your C++ code can be ported easily to x64 with a recompilation. And inline assembly, afaik, is not supported in x64 compilation.

[shadowx360]

Thanks for the advice guys, I just want to optimize a few functions, and sometimes, it is hard to do so without getting deep down into the lower level coding.

[OReubens]

There are few cases where assembler will give you a significant increase in speed for the effort you're putting in.

This is particularly true in x86 type code because there is such a wide variety of cpu models and different memory architectures, cache layouts etc. that even if you do manage to get a speedup it's very likely to end up being slower than the equivalent C/C++ code if you try it out on another PC.

Writing optimised Assembly is hard... VERY hard... You are much more likely to produce faster running programs by rethinking what your program does and using algorithms that are better suited than trying to squeeze out a couple clockcycles here and there.

Profile your code first and see where the actual bottlenecks are. If your bottleneck is indeed the CPU not managing to keep up (very rarely) then you can consider assembly... most of the time the bottleneck is much more abstract than that... Memory bandwidth, cache misses, page faults, api calls etc... you aren't going to get any noticable increase in speed changing your code to assembly if that's your problem.

[shadowx360]

Thank you for your input, in that case, I'll post my code in a new thread and see if someone can speed it up any more.