Is a macro assembled into exe only ONCE or as many times as I call it???
Posted on 2002-05-22 06:15:43 by Jayrome
Each time a macro is called the assembler executes
the code in the macro - it is advanced cut-n-paste.
Posted on 2002-05-22 06:54:05 by bitRAKE
The way I think of macros is that they are in effect programs that run at compile time. That's really what they are, and you can make them very complicated and convoluted, with loops, decision blocks, and just about anything you can imagine.

A macro might just be a simple text substitution, or it may do some calculation based on some custom parameter you want to check, like if this is a debug version or release version, and do something different in each case.

The compiler scans your source code numerous times, top to bottom. I can make a good argument it does this at least THREE times.

The first pass is to "expand" the macros. If a macro contains coded or data, each time the macro is referenced it expands into the code or data. Note the phrase "when referenced." It means just having a macro in your code adds zero to the program. You have to use the macro somewhere to have it take effect.

Once the macros are expanded, the compilers next pass does the translation from assembly steps into op codes. The final pass is used to compute offsets, or the address of data items, jumps, and whatever else is used.
Posted on 2002-05-22 23:24:43 by Ernie
So it's really economy only at design time?
Posted on 2002-05-23 02:59:38 by Jayrome
Personally I think that MACRO's are redundant - and I am a lover of MASM - so shoot me !!

My argument is as follows:

If you need to call a particular chunk of code many times, then it should be defined as a procedure - that's what the ret instruction was created for !!
If your don't need to call it more than once, then it can be clearcoded - and if the only reason one can give for using a macro at all is that it makes for neat and readable sourcecode, then I reply that we can clearcode the function, then whack a copy into an includefile, and replace the original with an include statement.

Tell me what I am missing, the only macro I ever use is szText, and that I only use during development, through sheer laziness.

Don't think that I am a totally diehard lowlevel coder (though that may be true enough) because I do appreciate other highlevel constructs such as STRUCTS and the HLL directives (looping and such) which actually compile very nicely.

I am against dirty binary through laziness - I am not against laziness in general ok? :tongue:
Posted on 2002-05-23 03:17:32 by Homer
Manage our OOP system by hand, and see how redundant macro's are ;) (If your not familiar, its entirely, 876 lines of MACRO code).

But i totaly agree, it *can* be done by hand, but will be extremely error-proned, and time consuming. As well your code will look quite convolutied with 'typedef' etc. for masm to realize your intentions. Alot of the macro's rely on state information from other macros somewhere else in the file. This mean you'd have to continously update and monitor these states while coding.

However, All this is hidden and properly taken care for, by well placed macro's...

Hmm.. But then again you *can* counter with a "why not use a function to do all the setups, if its soo complicated". You can do this, and it works, but then you would have a needless amount of bloat in your final exe, to do at RUN-TIME, what some well designed macro's can do at COMPILE-TIME (and save the overhead).

IMO, they are far from redundant. ;)

NaN
Posted on 2002-05-23 04:03:43 by NaN
The capacity to "pre-process" text before assembly is a very powerful capacity to have that many compilers do not have. It allows you to change the structure of you code in many convenient ways.

NaN has a good point here, why waste executable code when you can pre-process it in macros and only have the code with the result.

The choice between a macro and a proc depends what you want to acheive, a macro can inline a set of instructions so that you avoid the stack overhead iof it is speed critical where a procedure only has to be written once but can be called many times.

Of course you can combine procs and macros to do even more interesting things. As long as you understand what they are doing, they are a useful part of the assembler language programmers arsenal of tools.

Regards,

hutch@movsd.com
Posted on 2002-05-23 07:41:20 by hutch--