News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

pmacros v2

Started by Petroizki, March 15, 2005, 05:14:22 PM

Previous topic - Next topic

Petroizki

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

pbrennick

I really don't see the point...

I can just do this:

fncall equ invoke

Sorry,
Paul

hutch--

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.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

Mark_Larson


  I agree with Hutch--.  You have some nice added functionality over invoke.  Gooo job :)
BIOS programmers do it fastest, hehe.  ;)

My Optimization webpage
htttp://www.website.masmforum.com/mark/index.htm

MazeGen

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.