flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > extending the proc/endp macros

Author
Thread Post new topic Reply to topic
technocrat



Joined: 22 Nov 2008
Posts: 4
technocrat 22 Nov 2008, 21:36
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?
Post 22 Nov 2008, 21:36
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7103
Location: Slovakia
vid 22 Nov 2008, 21:41
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 
}    
Post 22 Nov 2008, 21:41
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
technocrat



Joined: 22 Nov 2008
Posts: 4
technocrat 22 Nov 2008, 21:57
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.    
Post 22 Nov 2008, 21:57
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20686
Location: In your JS exploiting you and your system
revolution 22 Nov 2008, 22:03
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
Post 22 Nov 2008, 22:03
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 22 Nov 2008, 22:07
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.
Post 22 Nov 2008, 22:07
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 23 Nov 2008, 07:38
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).
Post 23 Nov 2008, 07:38
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8434
Location: Kraków, Poland
Tomasz Grysztar 23 Nov 2008, 10:08
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).
Post 23 Nov 2008, 10:08
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 23 Nov 2008, 11:19
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
Post 23 Nov 2008, 11:19
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8434
Location: Kraków, Poland
Tomasz Grysztar 23 Nov 2008, 12:32
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
Post 23 Nov 2008, 12:32
View user's profile Send private message Visit poster's website Reply with quote
technocrat



Joined: 22 Nov 2008
Posts: 4
technocrat 23 Nov 2008, 14:21
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?
Post 23 Nov 2008, 14:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20686
Location: In your JS exploiting you and your system
revolution 23 Nov 2008, 14:35
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.
Post 23 Nov 2008, 14:35
View user's profile Send private message Visit poster's website Reply with quote
technocrat



Joined: 22 Nov 2008
Posts: 4
technocrat 23 Nov 2008, 14:45
Thanks a lot! This worked fine. Sorry if I asked dumb questions here, but I'm still new to the macro language of FASM.
Post 23 Nov 2008, 14:45
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 23 Nov 2008, 14:53
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?
Post 23 Nov 2008, 14:53
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20686
Location: In your JS exploiting you and your system
revolution 23 Nov 2008, 15:02
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.
Post 23 Nov 2008, 15:02
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 23 Nov 2008, 19:16
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
Post 23 Nov 2008, 19:16
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8434
Location: Kraków, Poland
Tomasz Grysztar 23 Nov 2008, 19:49
baldr wrote:

SSSO is already broken — include expands environment variables… Wink

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.
Post 23 Nov 2008, 19:49
View user's profile Send private message Visit poster's website Reply with quote
KingDemon



Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania
KingDemon 10 Feb 2009, 00:31
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
Post 10 Feb 2009, 00:31
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.