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?
thanks,
will
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?
thanks,
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)
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)
Sweet!
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
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
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.
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
endif
:)
ifdif <length>,<ecx>
mov ecx,length
endif
:)
Here is an example of many nested macros:
The above macros replace:
XXX MACRO regmem:REQ, func:VARARG
% &func
EXITM <®mem>
ENDM
DXD MACRO dlabel:REQ
IFNDEF dlabel
_DATA segment
dlabel dd ?
_DATA ends
ENDIF
EXITM <[&dlabel]>
ENDM
CTEXT MACRO y:VARARG
LOCAL sym
CONST segment
IFIDNI <y>,<>
sym db 0
ELSE
sym db y,0
ENDIF
CONST ends
EXITM <OFFSET sym>
ENDMReadFromIni MACRO lpKey:REQ
invoke GetPrivateProfileInt,CTEXT("ReallyRad"),lpKey,TRUE,lpIniFile
ENDM
ReadOptions PROC
FOR arg, <AddDlg, AddMnu, AddRes, AddVer, AddFile, AddFolder, CtlClk, MnuSel, CtlNme>
mov DXD(f&arg), XXX(eax, ReadFromIni CTEXT('&arg'))
ENDM
ret
ReadOptions ENDPThe above macros replace:
.const
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
.data
fAddDlg dd ?
fAddMnu dd ?
fAddRes dd ?
fAddVer dd ?
fAddFile dd ?
fAddFolder dd ?
fCtlClk dd ?
fMnuSel dd ?
fCtlNme dd ?
.code
ReadFromIni proc lpKey:DWORD
invoke GetPrivateProfileInt,addr szReallyRad,lpKey,TRUE,lpIniFile
ret
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
ret
ReadOptions endp4oh4,
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. :)
Regards,
hutch@movsd.com
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. :)
Regards,
hutch@movsd.com
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.
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.