I don't have a disassembler at work, so I can't check right now...

How do macros work? I mean does masm just insert that compiled code into every place where you call the macro from, or is it more like a proc where the proc only exists once and is referenced with a jmp?

The reason why I ask is because I was trying to cut down on executable size (not to mention typing) by putting a routine that I use about 7 times in a macro rather than typing it all out in place. But the executable size didn't decrease at all. So I presume that masm just 'inserts' the code contained in the macro at every point where I call the macro. Is that right? If so I'd be better off throwing that code in a proc instead? On that note, if you're dealing with a good sized chunk of code, is it plain old good practice to put it in a proc anyways? What I mean by that is, are macros designed for small amounts of code?

Posted on 2002-04-26 16:58:16 by Will
your right about macros ....
they just insert the code at the place you call the macro ...
so if your looking to cut the size by using a proc insted of a macro then it will help depending on how much you really call that macro..
macros = larger size + faster program
proc = smaller size + slower program
(thats what I know but I'm not an expert)
Posted on 2002-04-26 17:08:22 by code1101

I guess even bad asm coders (like me) don't really have to worry much about size, but I really should put that code in a proc instead of a macro. For the time being I only call it 7 times but that'll change as the project progresses.

Thanks a bunch
Posted on 2002-04-26 17:14:30 by Will
The way I think about it is automated cut-n-paste. There are a bunch of conditional options to make this easier, but it's still all cut-n-paste. In fact all the arguments that are passed to a macro are strings. String replacements is how it happens.
Posted on 2002-04-26 17:25:54 by bitRAKE
A macro does generate the code every time it's used, but don't forget that the same macro can generate different code each time, depending on it's parms, etc. Consider the following:

ifdif <length>,<ecx>
mov ecx,length

Posted on 2002-04-26 20:15:02 by S/390
Here is an example of many nested macros:

% &func
EXITM <&regmem>

IFNDEF dlabel
_DATA segment
dlabel dd ?
_DATA ends
EXITM <[&dlabel]>

CONST segment
IFIDNI <y>,<>
sym db 0
sym db y,0
CONST ends
The above is from our macro toolbox, now the code:
ReadFromIni MACRO lpKey:REQ

invoke GetPrivateProfileInt,CTEXT("ReallyRad"),lpKey,TRUE,lpIniFile

ReadOptions PROC

FOR arg, <AddDlg, AddMnu, AddRes, AddVer, AddFile, AddFolder, CtlClk, MnuSel, CtlNme>
mov DXD(f&arg), XXX(eax, ReadFromIni CTEXT('&arg'))

ReadOptions ENDP
Some asm programmers shy away from such macros.
The above macros replace:

szReallyRad db 'ReallyRad',0
szAddDlg db 'AddDlg',0
szAddMnu db 'AddMnu',0
szAddRes db 'AddRes',0
szAddVer db 'AddVer',0
szAddFile db 'AddFile',0
szAddFolder db 'AddFolder',0


fAddDlg dd ?
fAddMnu dd ?
fAddRes dd ?
fAddVer dd ?
fAddFile dd ?
fAddFolder dd ?
fCtlClk dd ?
fMnuSel dd ?
fCtlNme dd ?


ReadFromIni proc lpKey:DWORD
invoke GetPrivateProfileInt,addr szReallyRad,lpKey,TRUE,lpIniFile
ReadFromIni endp

ReadOptions proc
invoke ReadFromIni,offset szAddDlg
mov fAddDlg,eax
invoke ReadFromIni,offset szAddMnu
mov fAddMnu,eax
invoke ReadFromIni,offset szAddRes
mov fAddRes,eax
invoke ReadFromIni,offset szAddVer
mov fAddVer,eax
invoke ReadFromIni,offset szAddFile
mov fAddFile,eax
invoke ReadFromIni,offset szAddFolder
mov fAddFolder,eax
invoke ReadFromIni,offset szCtlClk
mov fCtlClk,eax
invoke ReadFromIni,offset szMnuSel
mov fMnuSel,eax
invoke ReadFromIni,offset szCtlNme
mov fCtlNme,eax
ReadOptions endp
...and adding another option becomes very easy. :)
Posted on 2002-04-28 01:26:47 by bitRAKE

If its repetitious code that is not particularly speed critical, the trick is to put the proc call in a macro in whatever simplified form you like. get the best of both worlds. :)


Posted on 2002-04-28 04:46:02 by hutch--
Thanks for the great replies. Up till now I've pretty much ignored macros for whatever reason but they can be useful. I guess it's time to search back through the boards and study them a bit more.

Hutch, that's exactly it. It's not speed critical at all. In trying to decrease the size (which to be completely honest the program isn't that big at all) I got interested in macros and how masm deals with them.
Posted on 2002-04-28 13:33:55 by Will