I'm getting some practice with C and assembly mixed mode programs. I think I have the two talking to each other but I'm not completely positive, not enough to continue on quite yet anyway.
C Code:
Assembly code:
So my question is, are the two languages communicating with each other? So for example is hex1 in fact being moved into AX and is hex2 being moved into BX? Also what happens after the test procedure ends in the assembly program? Does it go back to my C program? Because "TEST" in C is being outputted.
Thanks for any help.
C Code:
#include <STDIO.H>
int main(void)
{
char hex1, hex2;
extern char test(char, char);
printf ("Enter first character: ");
scanf ("%c", &hex1);
while (getchar () != '\n')//so that the program doesn't take in the carriage return as input
continue;
printf ("Enter second character: ");
scanf ("%c", &hex2);
while (getchar () != '\n')//so that the program doesn't take in the carriage return as input
continue;
test(hex1, hex2);
printf("TEST");
}
Assembly code:
.model small
.data
.code
public _test
_test PROC
push BP
mov BP, SP
mov AX, ;get argument1 hex1
mov BX, ;get argument2 hex2
pop BP
ret ;stack cleared by c function
_test ENDP
END
So my question is, are the two languages communicating with each other? So for example is hex1 in fact being moved into AX and is hex2 being moved into BX? Also what happens after the test procedure ends in the assembly program? Does it go back to my C program? Because "TEST" in C is being outputted.
Thanks for any help.
See ObjAsm32, it supports C++ and VB interoperability, while based on MASM assembler, letting you mix as you wish. I am addicted to it.
OK it doesnt do multiple inheritance - but show me one good reason for using multiple inheritance that cannot be implemented using N-deep single inheritance plus satellite objects please.
OK it doesnt do multiple inheritance - but show me one good reason for using multiple inheritance that cannot be implemented using N-deep single inheritance plus satellite objects please.
Thanks for the tip, unfortunately I have to use what I'm using, if I do any projects that aren't school related I'll look into what you suggested.
MASM offers great help in C/Asm interfacing. Read more about .MODEL and PROC directives (especially their langtype parameter).
Thanks, its not a big issue, I was just wondering if my assembly procedure is actually being called/run and if the hex char's are indeed being put on the stack. As far as I think it should be doing just that. Any confirmations on this?
Depends on the calling convention. Looks like you are using STDCALL and yet you haven'y specified any in the C code. C compiler may assume the CDECL calling convention which is incompatible, to say the least.
In Visual C you do it this way: <type> <calling convention> <function name>(<parameters>);
in your case it would be:
As for your second question: "ret" is like "return" in C. .
In Visual C you do it this way: <type> <calling convention> <function name>(<parameters>);
in your case it would be:
extern char __stdcall test(char, char);As for your second question: "ret" is like "return" in C. .
Check returned value of test(hex1, hex2), if it is not equal to hex1, something is wrong. Most calling conventions (and cdecl too) expect returned value in al/ax/dx:ax (eax/edx:eax for 32-bit code). Result can be somewhat compiler-dependent (char parameters are promoted to int when passed to function, whether this promotion treats char as signed or unsigned depends on compiler and it's settings).
What C compiler are you using?
What C compiler are you using?
Thanks, its not a big issue, I was just wondering if my assembly procedure is actually being called/run and if the hex char's are indeed being put on the stack. As far as I think it should be doing just that. Any confirmations on this?
Best suggestion I can give you is, invest in a debugger. If you are doing DOS based stuff I would use turbo debugger as it's probably the best console mode debugger around. If you move onto 32-bit stuff get a copy of OllyDBG (basically the same layout as TD but graphical). With a debugger you can actually step through the program and watch what it does to the stack and various registers.
Also, like everyone else has said, if you are going to interface with C I suggest using the C calling convention. The easiest way to do this is:
_test PROC C hex1, hex2
mov AX, hex1
mov BX, hex2
ret
_test ENDPTruthfully, if you are going to go through the trouble of setting up your stack frame, accessing variables through BP and adjusting the stack afterwards. Why even use the PROC/ENDP directives? That's pretty much what those directives are for.