proc vs. macro (x86) 
Author Message
 proc vs. macro (x86)

hello,
anyone want to throw out ideas why one is better than the other or in what
situations one might be used over the other?  i'm new and don't quite
understand the difference.  is it like a preprocessor vs compile-time thing?
(for x86 assembly)

Thanks all,
spencer



Fri, 01 Nov 2002 03:00:00 GMT  
 proc vs. macro (x86)
On Mon, 15 May 2000 02:43:32 GMT, "Spencer Lee"

Quote:
> hello,
> anyone want to throw out ideas why one is better than the other or in what
> situations one might be used over the other?  i'm new and don't quite
> understand the difference.  is it like a preprocessor vs compile-time thing?
> (for x86 assembly)

> Thanks all,
> spencer

A procedure is a subroutine.  You write the code for it and it gets
included in your program one time.  It is executed by using the call
instruction.

A macro is a pattern of instructions that is inserted inline every
time you expand it.  If it is something you use a lot there can be
dozens or hundred copies of the code in your finished program.

Jack Klein
--
Home: http://jackklein.home.att.net



Fri, 01 Nov 2002 03:00:00 GMT  
 proc vs. macro (x86)
The difference in result is that a procedure is slower than a macro since it
has to push registers, jump to procedure and then pop registers, where as a
macro is fast but makes your code larger since the instructions are repeated
over and over every time you "call" the macro.

macro=fast+big



Fri, 01 Nov 2002 03:00:00 GMT  
 proc vs. macro (x86)

Icewalker a crit :

Quote:
> The difference in result is that a procedure is slower than a macro since it
> has to push registers, jump to procedure and then pop registers, where as a
> macro is fast but makes your code larger since the instructions are repeated
> over and over every time you "call" the macro.

> macro=fast+big

True, but what we call usually "procedure" is not only a "PROC" (available in
bad
assemblers). If a procedure is cleanly written, this is to say with a label, and

parameters transmited either by regs or in memory, the added time is only the
time for the CALL and the time for the RET (this is too say nothing if the
procedure
has a significant number of lines)

The final good trick, for me, is to have both: one (true clean) procedure called
with
a macro used only to set the parameters.

betov.



Fri, 01 Nov 2002 03:00:00 GMT  
 proc vs. macro (x86)


Quote:
> hello,
> anyone want to throw out ideas why one is better than the other or in what
> situations one might be used over the other?  i'm new and don't quite
> understand the difference.  is it like a preprocessor vs compile-time
thing?
> (for x86 assembly)

> Thanks all,
> spencer

A procedure is "processed" by the CPU.
A macro is "processed" by the assembler.

In very simple and limited situations, it is possible to have both
achieve nearly the same result;  that is, your program will execute
some sequence of instructions that achieve one thing or another.

At the basic level, the tradeoff between a procedure and a macro
is the fact that macros expand "in-line" at the point of the macro
invocation whereas a call to a procedure emits a single machine
instruction that transfers control to another location and saves
a return address so control can return to the first instruction beyond
the call upon procedure completion.  In this basic use of procs and
macros there are efficiency considerations:  The procedure/call
return mechanism requires execution time but only requires a single
copy of the procedure.  As long as the procedure is longer than
three bytes, or so, programs that use procedures (and make several
calls to procedures) wind up being shorter than programs that use
macros.

Macros, OTOH, expand their text in-line.  This has the performance
advantage of saving a call and return execution on each invocation
(over procedures).  However, because a copy of the code is made
on each invocation, heavy macro use tends to produce larger programs.

Macros are especially useful (in this basic mode) for very small code
segments.  For example, converting a lower case character in AL to
upper case is a job that is probably best done by a macro rather than
a procedure call.  If your procedure is long, then the execution time of
the procedure itself probably swamps the time required by the CALL
and RET instructions;  hence there is probably no practical benefit
to expanding the code in-line (i.e., procs are probably the best way
to proceed).

Note that macros have advanced uses that cause them to bear little
resemblance to procedures.  You can use macros to extend the
assembly *language*.  One trivial example is to change some mnemonics
around.  E.g., if you come from a Motorola background, you might
prefer instructions like "BNE" rather than "JNE".  Personally I feel that
this
is poor programming practice, but there are some examples where using
macros in this fashion can produce more readable code.

A better example of using macros in an advanced fashion is to add
HLL-like statements to your assembly programs.  For example, in the
"UCR Standard Library v2.0" system I've used MASM's macros
to implement a (nestable) try/exception/endtry sequence that allows
statements similar to the following:

    try

        geti32             ; Read an integer value into eax.

      exception ConversionError

         print  "Illegal character in input"

    endtry

try, exception, and entry are all part of the same macro "family".
They work together to handle exceptions (using a syntax familiar
to C++ or Delphi users).  BTW, geti32 and print simply expand
to CALL instructions in this example (the standard library provides
macros for nearly all routines in the library so you can skip the use
of the CALL instruction when calling one of these routines).

If the thought of using macros to extend the programming language
(or create a new programming language) intrigues you, then you
might want to take a look at HLA (the High Level Assembler).  Its
macro facilities were created specifically to allow this.
Example code included with HLA demonstrates how to use its
macro facilities to create all the standard HLL control structures
(IF, WHILE, REPEAT..UNTIL, FOR, etc).  You can find out more
about HLA at http://webster.cs.ucr.edu.
Randy Hyde



Fri, 01 Nov 2002 03:00:00 GMT  
 proc vs. macro (x86)

Quote:
> True, but what we call usually "procedure" is not only a "PROC"
(available in
> bad
> assemblers). If a procedure is cleanly written, this is to say with a

label,
[...]

   Hmm, why exactly 'PROC' is available in *bad* assemblers and the
label is a *clean* declaration of a procedure? FYI, in bad assemblers
if you don't use simplifiers there's no difference between PROC and
semicolon-style labels.

-- http://bphantom.hypermart.net --

-- Too many flames with too much to burn
And life's only made of paper --

Sent via Deja.com http://www.deja.com/
Before you buy.



Sat, 02 Nov 2002 03:00:00 GMT  
 proc vs. macro (x86)

[snip]

Quote:
> Note that macros have advanced uses that cause them to bear little
> resemblance to procedures.  You can use macros to extend the
> assembly *language*.  One trivial example is to change some mnemonics
> around.  E.g., if you come from a Motorola background, you might
> prefer instructions like "BNE" rather than "JNE".  Personally I feel
that
> this
> is poor programming practice, but there are some examples where using
> macros in this fashion can produce more readable code.

   You didn't leave me much room here to disagree with you ;-) However
altering mnemonic is the most likely topic for the task. Consider this
situation (sad but I had it for true):

   I need to compile CPU identification routines with both MASM 6.10
(up to 486 instructions) and the most recent MASM that is available
from MS (6.14 currently?). 6.10 doesn't certainly doesn't support the
CPUID instruction (and subsequent RDMSRs, too). So the most clean way
to handle that, IMO, is to set up .586 in MASM 6.11+, .486 in MASM 6.10
and use the macro:


CPUID MACRO
 DB 0Fh, 0A2h
ENDM
ENDIF

the rest of the code needs not to be changed.

[snip]

Quote:
> If the thought of using macros to extend the programming language
> (or create a new programming language) intrigues you, then you
> might want to take a look at HLA (the High Level Assembler).  Its
> macro facilities were created specifically to allow this.
> Example code included with HLA demonstrates how to use its
> macro facilities to create all the standard HLL control structures
> (IF, WHILE, REPEAT..UNTIL, FOR, etc).  You can find out more
> about HLA at http://webster.cs.ucr.edu.

   Macros can also be used very effectively for repeatable blocks of
code (e.g. REPEAT, FOR macros) , creating names and more.

-- http://bphantom.hypermart.net --

-- Too many flames with too much to burn
And life's only made of paper --

Sent via Deja.com http://www.deja.com/
Before you buy.



Sat, 02 Nov 2002 03:00:00 GMT  
 proc vs. macro (x86)


Quote:
>    You didn't leave me much room here to disagree with you ;-) However
> altering mnemonic is the most likely topic for the task. Consider this
> situation (sad but I had it for true):

>    I need to compile CPU identification routines with both MASM 6.10
> (up to 486 instructions) and the most recent MASM that is available
> from MS (6.14 currently?). 6.10 doesn't certainly doesn't support the
> CPUID instruction (and subsequent RDMSRs, too). So the most clean way
> to handle that, IMO, is to set up .586 in MASM 6.11+, .486 in MASM 6.10
> and use the macro:


> CPUID MACRO
>  DB 0Fh, 0A2h
> ENDM
> ENDIF

> the rest of the code needs not to be changed.

Yep, I complete missed extending the assembler when the CPU
outpaces the development tool.  Thanks for bringing that up.

Quote:
> [snip]

> > If the thought of using macros to extend the programming language
> > (or create a new programming language) intrigues you, then you
> > might want to take a look at HLA (the High Level Assembler).  Its
> > macro facilities were created specifically to allow this.
> > Example code included with HLA demonstrates how to use its
> > macro facilities to create all the standard HLL control structures
> > (IF, WHILE, REPEAT..UNTIL, FOR, etc).  You can find out more
> > about HLA at http://webster.cs.ucr.edu.

>    Macros can also be used very effectively for repeatable blocks of
> code (e.g. REPEAT, FOR macros) , creating names and more.

Yep, this is another thing I missed.  Primarily because I don't consider
these things macros any more than I consider conditional assembly
statements macros.  But since Microsoft calls them macros I have no
excuse for not mentioning these things, especially after having stated
how important they are in other posts.  (I prefer to call these things
"statements in the compile-time language"  while macros correspond
to "procedures in the compile-time language.").

Randy Hyde



Sat, 02 Nov 2002 03:00:00 GMT  
 proc vs. macro (x86)
Hello experts,

I would like to share a few unresolved thoughts of mine.

Writing a chess program in C++, I use 64 bits datastructures extensively.
The idea is this:

((PawnMask << 7) & ~FILEMASK[7]) & BlackPieces

gives me all pawncaptures to the right. If this is not imediately clear: I
am ANDing and ORing 64 bits bitmaps containing pieces (each bit represents
the square a certain piecetype is on) to produce moves and captures fast.

My problems are these:

a) My c compiler (BCB) refuses to "expand" inline asembly routines, with the
message "functions containing asm are not expanded inline". ASM experiments
show that the function call overhead of int LastBit(ui64 Map) is a very
unwanted 30%. Is there not some trick with __emit__ ?

b) The built-in >> (shift right) and << (shift left) for 64 bits operands,
are not inlined by the compiler, even with optimized settings. I depend on
these.

c) I am having bad results doing MMX asm. One should think the eight 64 bit
registers should be put to use in my case, or not? Is it my bad asm
programming, or are others having the same experience? One problem seems you
always have to load the mmx registers via a memory reference.

d) Is there no trick to let a C routine call a asm macro in some way?
Preferrably in a C-function style. I guess not. Sigh. And

Any thoughts, suggestions and pointers are greatly appreciated.

Bas Hamstra.



Wed, 06 Nov 2002 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. proc without stack frame OR macro instead of proc

2. macro -vs- macro/codeblock

3. NASM PROC macro

4. Macro v.s. Proc

5. MACRO or PROC?

6. NASM PROC macro

7. A macro involving two sub-macros - where the 2nd macro needs results from the first

8. proc {} vs. Method#to_proc

9. Proc.class vs yield

10. multiple values vs proc calls

11. x86 Solaris vs Sparc Solaris

12. TSR, proc near, proc far

 

 
Powered by phpBB® Forum Software