View Full Version : Assembly trouble (not too complicated)

03-05-2004, 01:56 AM
i had an assembly macro that i wrote that seems to compile at random. by that i mean that some places i put it will compile fine and work beautifully, and other places i put it wont compile at all. worst off all, they give really strange compiler errors.

i kept cutting things out to narrow down on the problem in one of the spots that it doesnt compile, and i ended up with this much non-compiling code:

__asm mov eax, val

this single, innocent line of code generates 6 compiler errors, all saying the same thing:

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

i can copy and paste this exact line of code to a different spot in my program and, after changing 'val' to something valid, it will happily compile.

while writing this post, i have figured out what causes the error, but i still dont understand why it does it. what i have discovered is this:

if the variable that i am putting in the register is a function argument, it wont compile. why can i not put function arguments in registers, but i can put any other type of variable in them?

03-05-2004, 02:25 AM
error C2400: inline assembler syntax error in 'second operand'; found 'newline'

The error you got seemed to indicate a newline problem :S I don't know what that has to do with arguments to functions...

03-05-2004, 01:30 PM
C or C++

I know in C++ you have to worry about name mangling.

03-05-2004, 02:43 PM
its C++, but it only happens to function arguments. the name mangling-should apply equally to all variables.

does this have something to do with the stack? from what i understand, you can access stack elements the same way you access normal memory if you have the address of them. i didn't think that would be a problem. and the newline thing doesnt seem to be sensical. like i said, i can copy and paste that exact line of code and have it use a non-argument variable and it works perfectly fine, so there is nothing wrong with the code itself from what i can tell.

03-05-2004, 03:29 PM
Try placing a semicolon at the end of that statement. Its best to use a block:

__asm {
/* .. */

03-05-2004, 04:41 PM
Any references to local variables should be placed in brackets.

And yes avoid single line inline assembly statements using __asm.

Here is a sample:

void Copy32(DWORD *Source,DWORD *Dest,DWORD size)
asm {
push ds
lds esi,[Source]
les edi,[Dest]
mov ecx,[size]
rep movsd

pop ds

You compiler is not parsing the line correctly so it is also not invoking the inline assembler. Since the compiler cannot compile the line it sees the end of line or new line character at the end of it and that is prob where your error is coming from. It's basically saying it cannot compile the line prior to the newline it has encountered.

03-05-2004, 05:44 PM
block, single line... it makes no difference.

i see what you are saying, but you are missing the point. it always fails whenever i am using a function argument, and only then.

this code:

mov eax, val

generates the same error as this code:

__asm mov eax, val

or even this one:

mov eax, val

and both lines of code work perfectly fine if val is not a function argument, be it local, global, or otherwise, and placing semicolons after the single line or the ending brackets does not fix the problem.

in summation:
it is only function arguments that cause this problem, and not the format of the line of code itself. the question still remains: why?

03-05-2004, 05:48 PM
Which compiler and which assembler

03-05-2004, 05:49 PM
oh sorry, i should have mentioned that before...


03-05-2004, 06:28 PM
I assume it is probably because of the stack. The inline assembler code might not know where to get the function arguments by itself.

The stack should look something like this:

local var
local var
local var
...however many local vars you have...
return address
return link
free address used for return value
parameter 1
parameter 2
parameter 3
...however many parameters you have...

03-05-2004, 06:39 PM
I'm lost because val in your examples is not part of a function argument.

mov eax,val1
push eax
mov eax,val2
push eax
call Add

push ebp
mov ebp,esp

;The following line(s) will be correct only with certain calling
;conventions - compilers will allow you to change the calling
;convention to be used
mov eax,[ebp+8] ;first passed parameter resides at ebp+8
add eax,[ebp+12]

pop ebp
ret ;same as return(val1+val2)

That is using val1 and val2 as function arguments and/or parameters.

mov eax, val

should work on any inline assembler provided that val is a valid variable.

mov eax,[immediate value 8/16/32] is perfectly valid in any x86 assembler provided the immediate value is of an integral type.

Post the entire section and perhaps we can help. Sometimes semi-colons in the wrong place or misplaced parentheses can spit out some strange errors. I don't think the error is in your assembly code.

03-05-2004, 06:58 PM
hum... wait a minute...

i just changed the variable i was using from "high" to "high_var" and it compiles now... :-\

is "high" a keyword or something? this may end up being a dumber problem than i previously thought...

03-05-2004, 07:06 PM
High probably extracts the high order bits from a WORD or DWORD and is probably pre-defined in your inline assembler. Look at the keywords that have been used in your inline assembler and you can answer this question.

But you have not given us enough info. All I see in your code examples is var, not high. Where did high come from?

03-05-2004, 08:30 PM
it was just a simple function to check between two variables and swap them if the high one was lower than the low one.

its fixed now, though, thanks anyways...

03-06-2004, 05:51 AM
Aargh, when I first read this post I entered "masm reserved words" into Google. "val" wasn't in the list. :-(

03-06-2004, 06:25 AM
Well for future reference post the code that is the trouble because what you posted and what you explained were two very different things.

Glad you got it fixed though.

03-06-2004, 03:56 PM
well, i was mistaken as to what the problem actually was.

i apologize.

03-06-2004, 04:51 PM
No problem. :)

Glad you got it working.