Thread: simple asm from vc++

"invoke" is a MASM macro that pushes the params, checks them against the "proto" statement and then issues a "call" instruction

VC++ doesn allow this macro because...well...theres no need for it....you arent going to get any time benefit from placing a call in an asm block.

If you relly must use an asm block, then simply push the params right to left and call the function...also check that the function isnt __cdecl because if it is, you will need to adjust the ESP register to balance the stack

Code:

#include <iostream>
using std::cout;
using std::endl;


void __cdecl foo(int x){
	cout << "Number passed was " << x << endl;
}

void __stdcall bar(int x){
	cout << "Number passed was " << x << endl;
}

int main (){

	int x = 10;

	//foo(x);
	__asm{
		push x//push param
		call foo//issue call
		add ESP,4//balance stack
	}

	//bar(x);
	__asm{
		push x//push param
		call bar//issue call...no stack bal as __stdcall
	}
	
    return 0;
}

Also bear in mind that your win32 function might be a macro (I believe DialogBox(..) is one), in which case you'll have to look at the macro to establish the actual function name and parameters.

Originally posted by Fordy
"invoke" is a MASM macro that pushes the params, checks them against the "proto" statement and then issues a "call" instruction

VC++ doesn allow this macro because...well...theres no need for it....you arent going to get any time benefit from placing a call in an asm block.

If you relly must use an asm block, then simply push the params right to left and call the function...also check that the function isnt __cdecl because if it is, you will need to adjust the ESP register to balance the stack

Fordy, I'm studying Motorola 68K right now. Just curious, if you don't adjust the stack will you get boundary errors or what? Will it randomly crash or gauranteed crash? Thanks.

P.S. - Starting x86 in a few weeks.

I dont know about the processor you are using....unfortunately my own basic knowledge is limited to 0x86 stuff...

But from that perpective, stack balancing is very important as the stack is relied upon to (among other things) guide the way code goes back and forth between procedures....

When you issue a call instruction, it pushes the address of the next instruction onto the stack...then when the called function ends, it ends with a ret instruction which basically jumps the execution of code to the address that's sat at the top of the stack....so say you call a procedure in the middle of your code, and it does not take care on how the stack is balanced, the ret instruction will read whatevers on the top of the stack. Now in this sitation this could send the flow of execution more or less anywhere...and will most likely end in an exception which will crash your app

Originally posted by Fordy
I dont know about the processor you are using....unfortunately my own basic knowledge is limited to 0x86 stuff...

But from that perpective, stack balancing is very important as the stack is relied upon to (among other things) guide the way code goes back and forth between procedures....

When you issue a call instruction, it pushes the address of the next instruction onto the stack...then when the called function ends, it ends with a ret instruction which basically jumps the execution of code to the address that's sat at the top of the stack....so say you call a procedure in the middle of your code, and it does not take care on how the stack is balanced, the ret instruction will read whatevers on the top of the stack. Now in this sitation this could send the flow of execution more or less anywhere...and will most likely end in an exception which will crash your app

The Motorola 68K isn't really good for anything except teaching. It is very simple for example, all of the Data registers are inuitevly labeled D0 - D7 and the address registers are A0 - A7 ( with A7 being the stack pointer ). They use "branch" instead of jump like intel. The real reason am I learning it is because this is the processor for the Color Gameboy. Due to non-disclosure I cannot write more but you get the idea

P.S. - Thanks for clearing up the padding.

>>Due to non-disclosure I cannot write more but you get the idea

Ok....big secret...I get it