What is better to use MACRO or PROC ?

what is faster or better.
Posted on 2002-11-26 07:02:34 by drakoforma
Its comparing apples to oranges...
They are similar, but not the same...

A macro is expanded at assemble time, while a proc is jumpped to at run-time.
Macros will replicate the code each time they are called, but will avoid the calling overhead, procs will be a single body of code.

Which you choose depends on your problem.

Mirno
Posted on 2002-11-26 07:19:04 by Mirno
Macro repeats it's content whenever it gets called, proc doesn't. They are both completely different things, even tho you might be able to achieve the same using either one of them.

Look as a Macro only as a helpful 'copy-paste' and a proc as a more evolved context-specific function.


Posted on 2002-11-26 07:21:34 by JimmyClif
Use both together. MACROs can create PROCs, but PROCs can't create MACROs. :)
Posted on 2002-11-26 07:51:49 by bitRAKE
Which is better?

A brick layer, or a tool-shed..?

Macro's and Proc's are fundementally different....
:alright:
NaN
Posted on 2002-11-26 23:28:33 by NaN
What is the speed of a text Marco size of under 20 bytes and a max of 128 bytes verses a PUSH / INVOKE of the string from a buffer.... I am taking about Icz small text Marco used in most of the Tutes..

I am sure that PUSH is faster but by HOW MUCH... 20% , 50% or 1000% difference. Have someone actually clocked this type for small text strings. If so the information about this will prove very helpful. If it not by Tooooooo much i may start back to using the Text marco for small strings more often.

Maybe a Single Cut and Paste may beat a push for every SINGLE Byte with one per Clock per Byte.

There is nothing like having a good a tool-shed i hear.... Posted on 2002-11-27 00:47:29 by cmax
Eh, just wanted to point out that it should be "macro" not "marco" (I thought that was a typo but apparently not :) Maybe it was a tripple typo .:eek: )

Anyway, macros are almost always faster but less practical sometimes. If the macro is used many times in non-critical code you should change it to a proc to save space.
Posted on 2002-11-28 00:44:16 by gliptic
Thx:rolleyes:
Posted on 2002-11-28 14:19:51 by drakoforma

What is the speed of a text Marco size of under 20 bytes and a max of 128 bytes verses a PUSH / INVOKE of the string from a buffer.... I am taking about Icz small text Marco used in most of the Tutes..


Anyway, macros are almost always faster but less practical sometimes. If the macro is used many times in non-critical code you should change it to a proc to save space.

Ok, i admit, i havent looked at these tut's before this reply but:
    [*]Macros are compile time tools (not run time).
    [*]push/pop & all other Intel Op-codes are run-time instructions. (Not compile time).
    [*]Macros are a first pass: compile-to-assembly.
    [*]Assembly to binary is the next (multiple) passes.


    Therefor:

      [*]You can't compare compile time Macro's to run time op-codes, and judge for efficiency. They are Apples-to-Oranges.

      Glypic is also correct in his statement, but it is ill-qualified with regard to the question presented.

      Macro's are like a rubber stamp, pounded into your code. They are not like functions, even tho they may seem like it when you use them. Funcitons exist in binary files only once, and all calls to them jump to its location, and jump back. Macros translate into the code, as they are scriped to "Stamp" into your ASM file, every time it finds an indication to do so.

      So as glypic said, "If the macro is used many times in your code you should change it to a proc to save space". Quick accounting here:

        [*]Macro is defined with 20 lines of ASM code.
        [*]The macro appears 80 times in your program.
        [*]The first pass compile stamps in 1600 lines of ASM into your program.
        [*]The next passes assemble the ASM into your final binary exe.
        If the 20 lines of code was placed in a funciton: The final exe would only add approximately 20 lines of extra code for the calls to the funciton, and 20 lines for the function itself.

        40 vs. 1600

        I let you decide...
        :alright:
        NaN
Posted on 2002-11-28 22:11:04 by NaN
If the 20 lines of code was placed in a funciton: The final exe would only add approximately 20 lines of extra code for the calls to the funciton, and 20 lines for the function itself.

40 vs. 1600

I let you decide...


If the macro appears 80 times in your program and you want to change it to a proc, it would take up more that 40 lines of code.
You still need to use the instruction call to call the function which takes about 2 bytes(please correct me if I am wrong). Furthermore, call instruction is like any other instruction and will take up clock time.
Posted on 2002-11-28 22:39:01 by roticv
Originally posted by NaN
Quick accounting here:

    [*]Macro is defined with 20 lines of ASM code.
    [*]The macro appears 80 times in your program.

    If the 20 lines of code was placed in a funciton: The final exe would only add approximately 80 lines of extra code for the calls to the funciton, and 20 lines for the function itself.

    100 vs. 1600
If the MACRO appears 80 times, then it would need to be called 80 times if it was a PROC. Also, speedwise, there would be the overhead of 80*(CALL + RET + (?)). If a stack frame is created or parameters passed on the stack instead of by register then that (?) is going to be more. :)

MACROs should not be used for everything - just where it adds features and eases programming. This is usually small pieces of code - sizewise less than the bytes for a CALL/ENTER/LEAVE/RET. MACROs also add complexity to the code - if a documented system isn't used expect your code to look like hieroglyphics to anyone trying to read it - the learning curve goes through the roof.
Posted on 2002-11-29 00:01:33 by bitRAKE
BitRAKE, thank you for catching this obvious mistake ;)

As for the call/ret business, i too realized this but didnt want to bring the conversation necessarily to this level, which is why i had chosen the word 'approximately' to follow the mistaken 20 lines.... et. al. ;)

At any rate, i hope this business is clear for cmax, gliptic, and drakoforma...
:alright:
NaN
Posted on 2002-11-29 23:48:19 by NaN
Thanks NaN and bitRAKE for the detailed information about this. OK let say i don't care about the bloat that a Marco my produce. So with the Marco being set up in the execution-able at compile time this would mean that the macro has already done it job and now ALL code is SET, so when i click a button to a code that is using a marco it will run JUST as FAST as when i click a code that jump Procedure BUT the only advange here is that i will not be jumping to anything because the code is right there, there is no more CUT and PASTE because it was all done at compile time ... Is this right the marco would be fasters because the code is already there and don't have to call this again right

szText MACRO Name, Text:VARARG
LOCAL lbl
jmp lbl
Name db Text,0
lbl:
ENDM

So it don't have to jump to the above statement ever again because it has already been Stamped in-line with the code that i clicked the button for. If so this only save the time of typing in code in-line as opose to using a procedure, all this to mean that using Marcos is faster only because i am not calling a procedure because the code is ALREADY there. In-line code is all that is... If i got this right thanks extra, extra for the well explanation about Marco's. Bottom line it's is not bloat if in-line programming is what a programmer wanted to do in the first place, it's only a typing time saver as opose to using a procecdure :)

No back to reality
I though it has to call the Marco everytime all over again just like it call a procudure... or is this wrong.
I always use message box to see what i have done and sometimes i do have seen that LEFT-OVER e : some where in esi reg indicating a cut and paste of the marco... What that all about, is it still cutting and pasting if so something is not right. You can dump the code and you see this in the code section all bundled together but down deep in the page where the code is using that marco there is no ...e :

So this lead me back to belever that there is no extra line (code) per say that should be there because it was suppose to be done at compile time. This is what makes it all so confussing. It seems like it is still cutting and pasting the SAME line just like you would push a line from the data section but it's only in the code section with the e: waiting to be used. This is what make me confussed about marcos. It may not be doing a full in-line, only a ref thing to force a call to the marco and if that is true i would rather type it in-line or use procedures.
This is why i alway ask about marco, so i can find the truth again what i see and thing that e: do.

the marco symbol in mem is a e with 2 dots over it and in back of it
Posted on 2002-12-01 09:52:07 by cmax