Inline asm issue in VC++ 6

[Hell-Lord]

Thats exactly what i was asking. Didn't sound right?

[Barabajagal]

Correct me if I'm wrong, but isn't the processor brand unimportant?

[Warrior]

There are processor brand specific features in x86 and certain things different processor models from either Intel or AMD support.

[Barabajagal]

setting something to null doesn't sound very much like a feature...

[warz]

I'm just messing around with inline assembly in MS VC++ 6. Here is the code I am working on:

Code Select Expand

__asm {
mov eax, 0
push eax
call GetModuleHandle
mov [hInstance], eax
mov eax, [hInstance]
push eax
mov eax, IDD_MAINFORM
push eax
mov eax, NULL
push eax
mov eax, MainDlgProc
push eax
call DialogBoxParam
}

Now, the error I get is:

error C2400: inline assembler syntax error in 'second operand'; found ')'

Now, I'm not VC++ expert or asm expert, so I really have no clue why this would happen. For all I know the answer to this is very simple. I'm also not sure where this ')' is located when the error refers to it. Hopefully someone can help me out with this.

Yegg, there's a few things I see here. DialogBoxParam is most likely stdcall, meaning that when parameters are pushed onto the stack, they're pulled off in the same stack-like fashion - first on, last off. So, essentially, you have to push the parameters in a reverse order. Currently, you are passing the parameters backwards. See this page, it's very helpful while learning asm (or i thought, anyways).

Another thing you might want to try is, if the calling convention correction doesn't fix anything, to push the value stored inside hInstance, rather than the memory address pointed to by that value.

Last, using null should be ok, but i'd get into the practice of xor'ing eax by eax.

[Hell-Lord]

I would also attempt using the AT&T syntax instead of the Intel one.

[Joe[x86]]

You can't set an WORD to null. You set it to 0. If you set it to null, literally, a chunk of your processor would disappear, because it'd be turned to null. Think about it.

xor eax, eax is the proper way to execute that instruction. If you're crashing, it's something else.

Note that:

Code Select Expand

mov [hInstance], eax
mov eax, [hInstance]

.. is equivalent to ..

*hInstance = eax;
eax = *hInstance;

I can't see if you use hInstance anywhere else, but if you don't the first line is unnessary, and the second line is unnecessary no matter what you do. I'm not sure if you know (I figure you do, but what's it hurt?), but the return value of a function is put to eax, so..

Code Select Expand

call GetModuleHandle

.. is equivalent to ..

int eax = GetModuleHandle();

EDIT -

I took the liberty of some personal investigation of this. Here's your code, edited up a bit and commented with current stack state:

Code Select Expand

XOR  EAX, EAX
PUSH EAX ; stack: 0
CALL GetModuleHandle
PUSH EAX ; stack: hInstance, 0
MOV  EAX, IDD_MAINFORM
PUSH EAX ; stack: IDD_MAINFORM, hInstance, 0
XOR  EAX, EAX
PUSH EAX ; stack: 0, IDD_MAINFORM, hInstance, 0
MOV  EAX, MainDlgProc
PUSH EAX ; stack: MainDlgProc, 0, IDD_MAINFORM, hInstance, 0
CALL DialogBoxParam ; DialogBoxParam(MainDlgProc, 0, IDD_MAINFORM, hInstance, 0);

According to this MSDN page, DialogBoxParam is called as INT_PTR DialogBoxParam(HINSTANCE hInstance, LPCTSTR lpTemplateName, HWND hWndParent, DLGPROC lpDialogFunc, LPARAM dwInitParam); however you appear to mixing up argument's being passed to it. You're sending it the right number of arguments, so I don't think you destroyed the stack, but calling it incorectly is still reason for the program to crash, I believe.

[Hell-Lord]

AT & T syntax ain't bad so what do you have against it?

[Joe[x86]]

Maybe I'm thinking of a different syntax, whatever GNU asm uses, but I tried it out once and could never understand it.

[Hell-Lord]

Yea it is a little different.....

Intel Snytax:

Code Select Expand

mov        eax, edx    

AT & T:

Code Select Expand

mov        %edx, %eax

[Joe[x86]]

Yeah, I don't know, I guess it's an aquired taste, but I just don't like it.

"Men are always in a rut, and they like it that way. If you want to progress in life, then there goes your nice comfortable rut."
- Dan Conner (paraphrased), Rosanne.

[Hell-Lord]

x86] link=topic=16593.msg167746#msg167746 date=1176093611]
Yeah, I don't know, I guess it's an aquired taste, but I just don't like it.

"Men are always in a rut, and they like it that way. If you want to progress in life, then there goes your nice comfortable rut."
- Dan Conner (paraphrased), Rosanne.

lol

anyway was bored and found this.....

+------------------------------+------------------------------------+
|       Intel Code                |      AT&T Code                     |
+------------------------------+------------------------------------+
| mov     eax,1                   |  movl    $1,%eax                   |   
| mov     ebx,0ffh               |  movl    $0xff,%ebx                |   
| int     80h                        |  int     $0x80                     |   
| mov     ebx, eax              |  movl    %eax, %ebx                |
| mov     eax,[ecx]             |  movl    (%ecx),%eax               |
| mov     eax,[ebx+3] |  movl    3(%ebx),%eax              |
| mov     eax,[ebx+20h]      |  movl    0x20(%ebx),%eax           |
| add     eax,[ebx+ecx*2h] |  addl    (%ebx,%ecx,0x2),%eax      |
| lea     eax,[ebx+ecx]        |  leal    (%ebx,%ecx),%eax          |
| sub     eax,[ebx+ecx*4h-20h] |  subl    -0x20(%ebx,%ecx,0x4),%eax |
+------------------------------+------------------------------------+

***Edit***
fixed the quote a little.

[MyndFyre]

x86] link=topic=16593.msg167739#msg167739 date=1176092182]
You can't set an WORD to null. You set it to 0. If you set it to null, literally, a chunk of your processor would disappear, because it'd be turned to null. Think about it.

WTF?  Null is another name for 0.  You can xor dx, dx, or xor dl, dl.  You can set any size of a value in a register or memory/stack variable to null.

Joe, really man, try to not spout false information.

[warz]

Joe, also, please, look at the MSDN page for DialogBoxParam, and check out the parameters. You're not even passing the correct parameters at the correct location. Did you say you tested that code? How did this work? The hInstance variable should be the last item pushed onto the stack, not the dialog box procedure function pointer - it seems like you have them out of order completely, because the dialog proc function pointer shouldn't be first onto the stack or last for that matter.

[Warrior]

setting something to null doesn't sound very much like a feature...

I never said it was.