This shouldn't compile, should it? (Or have I missed something, again?)
macro SPrint lpstring, tmp {

invoke lstrlen, lpstring
lea ebx, tmp
invoke WriteConsole, [hStdOut], lpstring, eax,ebx,0
}
...

SPrint "TEST",[.ddTemp]

I wonder, why does this work, I had typed above and had forgotten to make a "real" string in my .data section and put the adress instead of "TEST", but I compiled (not thinking of it), no error, and ran the app and it worked, and when I looked in to my sources I saw my misstake.
I tried to find some explanation in the fasm doc (searched for string), but I couldn't find any explanation. Does this have something to do with my use of a macro?
I'll take a second look in to the fasm doc again, I feel a little confused here... :confused:
Posted on 2003-06-08 06:48:36 by scientica
Look at "invoke" definition. The last invoke macro allows (and creates in .code section) strings as parameters.
Posted on 2003-06-08 09:42:28 by JohnFound
Aha! Now I see it inside the pushd macro, thanks. :)
Know when I know what happens when I'm careless/unmindful, I think I'll use this feature when doing pre-alpha version of functions.
Posted on 2003-06-08 12:05:00 by scientica
This case is small example, how sometimes use of macroses can make source unclear and less readable. BTW: I never use this feature of invoke. It's too "High level" for me. :grin:
Posted on 2003-06-08 18:08:41 by JohnFound

This case is small example, how sometimes use of macroses can make source unclear and less readable. BTW: I never use this feature of invoke. It's too "High level" for me. :grin:

But we use High Level solutions when we wan't screw up quick ;)
(seriously, I'll only use it when I'm lazy or forget something, "never" for public releases (flame when when something like that goes throught... :rolleyes: :grin: ))
Posted on 2003-06-09 05:05:08 by scientica

BTW: I never use this feature of invoke. It's too "High level" for me.

Really??? You'd rather do "push, push, push, push, call" than a one-line invoke? I'm not criticizing what you're saying, I just don't understand it. Can you explain why you feel it's better to write all those push's in reverse order than to have the call in one line of code, with arguments in the "proper" order?

I know what you mean about too many macros making a program hard to read, that's definitely true. But I think a few of the right macros can not only improve the readability, but also make it coding much less error-prone. Am I wrong in thinking this? Please enlighten me! :grin:
Posted on 2003-06-11 23:57:40 by MANT
To MANT:
Really??? You'd rather do "push, push, push, push, call" than a one-line invoke? I'm not criticizing what you're saying, I just don't understand it. Can you explain why you feel it's better to write all those push's in reverse order than to have the call in one line of code, with arguments in the "proper" order?


No, generally I don't make "push, push, push, .... call". I am using "invoke" macro. But I never use "advanced" invoke like this:

invoke someproc, "some string", ax, bx, cx

where the "invoke" macro creates automatically some string in the code memory, uses it and then jumps over it to the next instruction. If I need it I make it manually with all responsibility and understanding what I am actually made. :grin:

So, more about Invoke:

Using of invoke is easy and make programs MORE readable, BUT, in some cases it makes the code less optimised, for example here is some snippet of my real application code:


...
invoke SelectObject,[DC],eax
push eax ; temporary store eax in stack.

mov esi,[.v]
mov ebx,[x]
add esi,18
add ebx,18
invoke MoveToEx,[DC],[x],esi,NULL
invoke LineTo,[DC],[x],[.v]
invoke LineTo,[DC],ebx,[.v]

pop eax
invoke SelectObject,[DC],eax


The last 2 lines are extremely stupid! They will be assembled following way:



pop eax
push eax
push [DC]
call [SelectObject]


The right way to do this is simply:


invoke SelectObject, [DC]


But this is unreadable, because you must read some lines in above source to understand why SelectObject have only one argument and why this is not an error.

So, what I wrote in real project:



; pop eax
invoke SelectObject, ;,eax The eax is in stack, don't pop/push again



So, at the end I want to say that this kind (and similar) of "invoke" problems are very common and are the price that we pay for convenience to use HLL constructions.

BTW: The real HLL languages are in better position, because they have optimiser that detects and discards this kind of problems during compilation.
Posted on 2003-06-12 01:23:51 by JohnFound
OK, yeah, that makes sense, and I agree with everything you said. :alright:
Posted on 2003-06-12 02:20:37 by MANT