Not sure if this is the board for these but... 1) On the invoke macro: are you storing a frame pointer? & what would be the macro syntax for returning a value... because the returns are usually before the frame pointer & local vars. 2) Is there a way to see what the masm built in macros expand to w/o looing at binary dumps? 3) The masm "macros" often aren't, in the strict sense of the word (lexical replacement only)... when I see phrase "the assembler optimizes" that says to me that they're sometimes really "micro compiles." Am I correct on this? I really don't have a macho hard-on for "true assembler" it's just that for now it would have been educational to see the "man behind the curtian." In the future, when I get better, I may want to use these macros as a template but have the ability to override/optimize the generated code...
Posted on 2001-04-01 13:36:00 by rafe
1. ========= Nope (not me neither MASM :D ) invoke is a macro that just gets the parameters and pushes them in reverse order (STDCALL convention) then it calls the Win32API function given as the first parameter. Usually only PROC's (procedures) create a stack frame and use local variables :) but there is no need for stack frame here as you call and API Usually API return value in eax or a structure (offset/lp of the strucrure is a parameter to the API) 2. ========= yes of course there is a way, create a listing file when you assemble, i belive is the "/l" switch, you will have all the expanded macro code inside (i dont remember is there a switch for that also .. ? ) 3. ======== yeah somehow very basic macros are the building blocks for a compiler :D, and yes MASM tries to optimize jumps and some other parts of the macro code it generates
Posted on 2001-04-01 16:32:00 by BogdanOntanu
#2 - You can use the /Sg command line option, or the .LISTALL directive in the source, to produce generated code for INVOKE, IF, PROC, etc. in the listing file. :)
Posted on 2001-04-01 17:08:00 by S/390
rafe, The built in macros in masm are not always the optimal code in every instance of where they can be used, in areas like a WndProc procedure where the clarity of logic is the important thing, the standard "invoke" ".if" and similar make clear and maintainable code. At the opposite end of the spectrum, in the middle of an intensive loop, the occasional extra instruction can be a problem that slows down the complete algorithm. The real distinction is between being able to code complex logic as against the occasional close range optimisation and they both have their place, trying to manually code a WndProc style procedure with CMP/JNE at multiple levels of nesting to anonymous labels produces nightmares that are nearly impossible to maintain or get going. Regards, hutch@pbq.com.au
Posted on 2001-04-01 19:45:00 by hutch--
holla Leute,Grad brauche ich Winimage, um einen Linuxrouter zu bauen u. entdecke dabei, dass auch Win32s gebraucht wird.da lande ich auf Eurer Site.Ich bedanke mich fuer die moeglichkeit mich umfassend informieren zu koennen u. die downloads.In the right moment "tanks"null
Posted on 2001-04-02 02:33:00 by cococ
cococ,guten morgan, but I really didn't understand what you said (alles gute!). :) Had someone tested two codes, one with Masm Macros (.if, .while, etc.) and other with just jz, jne, etc. and compared their speeds? I don't know but, will be differences? (one day I'll do that...:rolleyes:)
Posted on 2001-04-02 06:56:00 by wolfao