Thanks to MazeGen's ideas, i have made a new version of my macros, this should make things little more simpler. Locals can be now defined like it is done default in MASM (using PLOCAL keyword), and there is no longer need to use keywords PARAM and LOCAL.
These macros are a replacement for MASM's original proc definitions, they were designed to help me with my own prologue and epilogue, but also to access all parameters and locals via esp. What changes is the procedure definition and function calling. It has some extra stuff in it's own invoke.
For example here is the original 'StdErr' proc from MASM32 library:
StdErr proc lpszText:DWORD
LOCAL hOutPut:DWORD
LOCAL bWritten:DWORD
LOCAL sl:DWORD
invoke GetStdHandle, STD_ERROR_HANDLE
mov hOutPut, eax
invoke StrLen, lpszText
mov sl, eax
invoke WriteFile, hOutPut, lpszText, sl, ADDR bWritten, NULL
mov eax, bWritten
ret
StdErr endp
And here is it in pmacros (locals and params accessed via esp):
func StdErr, lpszText:DWORD
PLOCAL hOutput:DWORD
PLOCAL bWritten:DWORD
PLOCAL sl:DWORD
fncall GetStdHandle, STD_ERROR_HANDLE
mov hOutput, eax
fncall StrLen, lpszText
mov sl, eax
fncall WriteFile, hOutput, lpszText, sl, ADDR bWritten, NULL
mov eax, bWritten
ret
endf StdErr
On a simple function like this, there is nearly no difference on the original code, except the fact that ebp is not used and the function is aligned to 4 bytes.
Accessing locals and params via esp, is however quite difficult task, and it can only be done if the procedure is linear and predictable by the macros, and does not make spaghetti jumps (The functions also have the original ebp-way to be used in such cases). I have tried to explain this stuff in the help file a little, but for an non-native english speaker it's not easy..
When you use these function macros you will get some special prologues to make your life easier:
ALIGNSTACK - Forces the local stack to be aligned 16 bytes, useful for SIMD instructions!
FRAMES - Uses ebp to access locals and params, by default all this is done via esp.
MOVE - Moves preservable registers to the stack and back instead of pushing them.
NOALIGN - By default functions are always aligned to 4 bytes, with this it does not happen.
TIME - Allows you to use custom timing macros to benchmark your function at runtime.
An example of function, that moves it's registers to stack and aligns it's locals to 16 bytes:
func MyFunc, MOVE, ALIGNSTACK, uses ebx ebp
Function calls are done with either fncall or fnjmp. Both support direct string calling and immediate floating points, plus with fnjmp you can define your custom return point.
fncall MyFunc, 435.939, 26.0
fncall MessageBoxA, NULL, "Hello World", "...", MB_OK
fncall MessageBoxW, NULL, L"Hello World", L"...", MB_OK
fncall eax
mov ecx, @fncall(MyFunc)
fnjmp <OFFSET @F>, MyFunc
There is an help file, and i'm sorry i don't yet have any useful example codes to show, but maybe later.. :(
download: http://personal.inet.fi/atk/partsu/pmacros.zip
I really don't see the point...
I can just do this:
fncall equ invoke
Sorry,
Paul
If you use the OPTION Prologue / Epilogue and code the algo without a stack frame, invoke works fine with no stack frame but it looks like your macro is adding functionality so it may be very useful.
I agree with Hutch--. You have some nice added functionality over invoke. Gooo job :)
There were several attempts to code a macro set for direct access to procedure arguments and locals directly via ESP, but AFAIK none of them are widely used.
Petroizki's "pmacros" is probably the cleanest and the simplest method, how to figure that problem out in MASM. I believe it will be useful for wide range of masmers. There are, of course, some limitations to this method, but in general is it usable without any restrictions.
Enjoy :8)
I'm actually writing a "compatibility-mode plugin" to make the syntax even more simple. Hopefully it will be finished next week:
Quote
Compatibility-mode plugin for pmacros (c-m plugin)
Introduction:
When I familiarize myself with Petroizki's pmacros version 1.00, I decided to wrote my own modified version, which would be as close as possible to original syntax. In the meantime, Petroizki much improved pmacros and released version 2.00, which is closer to original syntax and therefore I broke my work.
Since I've came to conclusion version 2.00 is still far from original syntax (from my point of view), Petroizki has suggested a way to me how to avoid writing new, incompatible version of pmacros and also how to share my work with others, so I've started to write this ,,c-m plugin" for filling my needs.
Brief description:
C-m plugin enables the original syntax as close as possible. Using c-m plugin, the only syntax change is different definition of procedure, which uses direct esp stack frame (you need func/endf macros) and definition of its locals (you need plocal macro). It means mainly you get rid of underscored mnemonics (_push, _pop, ...) and you can use standard and original INVOKE directive with all its advantages (and disadvantages). Refer to Using c-m plugin for details about complications with INVOKE and functions with variable argument count or C calling convention.
BTW, pmacros's INVOKE replacement fncall and also your own INVOKE replacements can be used (almost) freely.
All of those advantages are enabled under additional conditions, but I believe they are balanced with advantages of c-m plugin.