extending the proc/endp macros

Index > Macroinstructions > extending the proc/endp macros

Author

Thread

technocrat

Joined: 22 Nov 2008
Posts: 4

technocrat

Hi there,

I want to wrap the existing proc/endp macros such that I have some code before and some code after each procedure. I tried it with something like that:

Code:

macro ext_proc proc_name, [args]
{
    dd 1
    proc proc_name, args
}

macro ext_endp
{
    endp
    dd 2
}

and macro invocations like:

Code:

ext_proc myproc
    ret
ext_endp

Of course, the 'dd's are just placeholders. But I'm getting already errors for the code above. What am I doing wrong? Or isn't it possible at all what I'd like to do?

22 Nov 2008, 21:36

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid

Macro with multi-arguments are by default processed for every argument. Use this:

Code:

macro ext_proc proc_name, [args] 
{ 
  common  ;<-
    dd 1 
    proc proc_name, args 
}

22 Nov 2008, 21:41

technocrat

Joined: 22 Nov 2008
Posts: 4

technocrat

Inserting that "common" doesn't seem to help. Let me show you the error message I get:

Code:

flat assembler  version 1.67.21  (1538034 kilobytes memory)
test.asm [103]:
ext_endp
macros.inc [219] ext_endp [1]:
    endp
D:\prog\fasm\include/macro/proc32.inc [219] endp [4]:
   match all,args@proc \{ restore all \}
error: invalid name.

22 Nov 2008, 21:57

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system

revolution

Because you have an extra comma in your definition

Code:

proc proc_name, args

You need to detect for an empty args parameter and not put the comma. Hint: Use match

22 Nov 2008, 22:03

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4633
Location: Argentina

LocoDelAssembly

Try with

Code:

macro ext_proc [args]
{ 
common  ;<-
  dd 1
  proc args
}

PROC macro supports more than one symbol in the name parameter, this way will fix the problem completely.

22 Nov 2008, 22:07

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

vid, revolution and LocoDelAssembly,

I think the effect of implicit forward should be emphasized in FASM.PDF, because macro stoschar example seems to be not enough (it uses the effect, not explains it).

23 Nov 2008, 07:38

Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland

Tomasz Grysztar

documentation wrote:

Block of instructions that follows forward directive is processed for each group of arguments, from first to last - exactly like the default block (not preceded by any of these directives).

23 Nov 2008, 10:08

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

Tomasz Grysztar,

May be it deserves separate paragraph. It's so easy to step on the trap, sooner or later…

By the way, are you going to update FASM.PDF? -d and -s options, for example… Wink

23 Nov 2008, 11:19

Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland

Tomasz Grysztar

Yes, the documentation is going to be updated with the "stable" release (the 1.68 one). It needs to cover the new SSE extesions and other recent additions, too.

However I don't plan documenting the -d option - I consider it semi-official, since it breaks the SSSO principle. Wink

23 Nov 2008, 12:32

technocrat

Joined: 22 Nov 2008
Posts: 4

technocrat

Thanks for your quick replies. Unfortunately, I used the additional first macro parameter 'proc_name', because I wanted to create a label with that name and then pass a slightly modified name to the invocation of the 'proc' macro. In my current solution I avoid using the 'proc' macro from inside another macro. It looks like this:

Code:

crypt_proc encryption_test

proc encryption_test_int
    ret
endp

crypt_endp encryption_test

However, I'd really like to have the 'proc' and 'endp' invocations inside the crypt_proc and crypt_endp macros, respectively, such that using these macros will look like:

Code:

crypt_proc encryption_test
    ret
crypt_endp encryption_test

But my problem is that I don't know how to declare the label 'encryption_test' in crypt_proc while invoking 'proc' with 'encryption_test_int'. Can anyone help me with that problem?

23 Nov 2008, 14:21

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system

revolution

Why not just use your original macros with a small change as I hinted to earlier with match?

Code:

macro ext_proc proc_name, [args]
{  common ;don't forget this
    dd 1
  match =x,x args \{ ;empty args
    proc proc_name
  \}
  match a,args \{ ;used args
    proc proc_name, args
  \}
}

Note: This is just off the bat, I haven't tested it so perhaps it will fail, but I hope it gives you the basic idea.

23 Nov 2008, 14:35

technocrat

Joined: 22 Nov 2008
Posts: 4

technocrat

Thanks a lot! This worked fine. Sorry if I asked dumb questions here, but I'm still new to the macro language of FASM.

23 Nov 2008, 14:45

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

Tomasz Grysztar,

SSSO is already broken — include expands environment variables… Wink

revolution,

Even match ,args \{ proc proc_name \} will suffice. Or may be I'd overlooked something?

23 Nov 2008, 14:53

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system

revolution

baldr wrote:

Even match ,args \{ proc proc_name \} will suffice. Or may be I'd overlooked something?

Yes, I had originally written that during my editing, but decided it might look to confusing and added the =x,x just to try and make it clearer.

23 Nov 2008, 15:02

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4633
Location: Argentina

LocoDelAssembly

Code:

macro ext_proc [args]
{
common ;don't forget this
  dd 1

  proc args ; Call first, if survives then arguments were valid (not mandatory, though)

  match name any, args 0\{ ;"0" because parameterless procs woulnd't match otherwise
    display \`name, 13, 10 ; Do your stuff here
  \}
}

Just to insist in using one argument Razz

23 Nov 2008, 19:16

Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland

Tomasz Grysztar

baldr wrote:

SSSO is already broken — include expands environment variables…

As I already explained in some other thread (I don't recall where was it), I don't consider this to be breaking the SSSO, because it doesn't change HOW the source is assembled, it only changes WHICH source is assembled.

23 Nov 2008, 19:49

KingDemon

Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania

KingDemon

Hi! I'm trying to do something similar, and for the love of god, I can't get it to work. I'm trying to add a "this" parameter to all procedures defined with my new macro:

Code:

macro comproc proc_name, [args]
{
 common
   match =x,x args \{ proc proc_name, this \}
   match a,args \{ proc proc_name, this, args \}
}

It compiles ok, but for some reason it crashes. It does work when I use "proc" directly, with the "this" parameter in the param list.. So what' wrong here?

EDIT: I just figured it out myself, so I'll post here:
There are two possible ways to call the above macro, both of which work, but render different results:

Code:

comproc test a, b, c
    ret
endp

Code:

comproc test, a, b, c  ;the difference here is the comma after the proc name
    ret
endp

The first comproc macro results in:

Code:

proc test a, this, b, c

while the second one does:

Code:

proc test this, a, b, c

Don't ask me why. I just figured it out with trial-and-error. Smile

10 Feb 2009, 00:31

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum