flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > Too many call macros?


Are there too many call macros
Yes
46%
 46%  [ 6 ]
No
53%
 53%  [ 7 ]
Total Votes : 13

Author
Thread Post new topic Reply to topic
silkodyssey



Joined: 02 Oct 2003
Posts: 205
Location: St.Vincent & the Grenadines
silkodyssey
It seems like the invoke macro doesn't work with api functions that don't accept any parameters and I have to use the call instruction instead. This is not a major issue but it means having to take time to decide which call macro I have to use. I think it would better to have one macro to call all types of functions. Is this feasible?

_________________
silkodyssey
Post 04 Sep 2004, 00:00
View user's profile Send private message MSN Messenger Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1095
Location: Poland
decard
You can use invoke maco for APIs with no parameters. Don't you have an older version?

BTW, S.T.A.S. has came with a solution that may interest you too - there are no invokes at all Smile see here: http://board.flatassembler.net/topic.php?t=1889
Post 04 Sep 2004, 07:25
View user's profile Send private message Visit poster's website Reply with quote
Foamplast



Joined: 07 May 2004
Posts: 36
Location: Saratov, Russia
Foamplast
Hello!
I use this set of macroses that helps to translate Platform SDK header files easily.

macro GetMessage [arg] { common win32apicall GetMessage_,arg }
GetMessage_% = 4

macro win32apicall proc, [arg] { common invoke proc, arg }

macro invoke proc,[arg] ; invoke procedure (indirect)
{
common
if ~ arg eq
stdcall [proc],arg
else
call [proc]
end if
}

macro stdcall proc,[arg] ; call procedure
{
reverse
pushd arg
common
call proc
}

macro invoke proc,[arg]
{ common local ..count
..count = 0
if ~ arg eq
forward ..count = ..count + 1
common
end if
if defined proc#%
if ..count <> proc#%
display 0Dh,0Ah,"error: invalid count of parameters for API call.",0Dh,0Ah,0Dh,0Ah
halt
end if
end if
invoke proc,arg
}
Post 04 Sep 2004, 23:32
View user's profile Send private message Visit poster's website Reply with quote
silkodyssey



Joined: 02 Oct 2003
Posts: 205
Location: St.Vincent & the Grenadines
silkodyssey
silkodyssey wrote:

It seems like the invoke macro doesn't work with api functions that don't accept any parameters and I have to use the call instruction instead


I don't have this problem when using the fresh macros and there are some ofher nifty macros in its macro library so I think I'll continue to use it. Smile

_________________
silkodyssey
Post 11 Sep 2004, 13:30
View user's profile Send private message MSN Messenger Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1095
Location: Poland
decard
BTW, I wish someday Privalov and John would finally design one macro library, used by both FASM and Fresh Confused
Post 11 Sep 2004, 19:42
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7498
Location: Kraków, Poland
Tomasz Grysztar
It's hard to satisfy everyone - maybe the "competitive" macro packages (the one from STAS is another example) are a good way to do it.
Post 11 Sep 2004, 19:57
View user's profile Send private message Visit poster's website Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
I maintain my own set of of macro libraries (taken from an older version of FASMW), it's slowly starting to change to better meet my needs. In reality, you can't satisfy everyone, so why try? Either deal with what's provided or roll your own. The advantage to doing them yourself is that you control them: they'll never change without warning Smile
Post 12 Sep 2004, 04:19
View user's profile Send private message Visit poster's website Reply with quote
Vortex



Joined: 17 Jun 2003
Posts: 335
Vortex
No problem with the existing call macros. Smile

_________________
Code it... That's all...
Post 12 Sep 2004, 09:05
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 875
Location: Colombia
pelaillo
Privalov wrote:
It's hard to satisfy everyone


But you do it! Wink Your strong opposition to hardcode the functionality that can be done using macros has done the work.

I try to follow the standard distribution but sometimes I need something different. For example I shall never use "invoke" in my sources (too ugly and damage the nice indentation of assembly code).
Post 12 Sep 2004, 17:00
View user's profile Send private message Yahoo Messenger Reply with quote
Vortex



Joined: 17 Jun 2003
Posts: 335
Vortex
Pelaillo,

What's wrong with the invoke macro?

_________________
Code it... That's all...
Post 12 Sep 2004, 19:56
View user's profile Send private message Visit poster's website Reply with quote
silkodyssey



Joined: 02 Oct 2003
Posts: 205
Location: St.Vincent & the Grenadines
silkodyssey
pelaillo wrote:

I try to follow the standard distribution but sometimes I need something different. For example I shall never use "invoke" in my sources (too ugly and damage the nice indentation of assembly code).


You just need to indent a little more. Smile

_________________
silkodyssey
Post 12 Sep 2004, 19:57
View user's profile Send private message MSN Messenger Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1095
Location: Poland
decard
I think that the most elegant (and proably the most commonly used here) indent method following: you press tab once, write an instrution (or some macro, like invoke or stdcall), then press tab once again, and write instruction (macro) arguments. If tab size is set to 8 spaces, this way your code looks very clear, and invokes don't break the indentation. BTW, it is used in FASM and Fresh sources. Why not to use it too?
Post 12 Sep 2004, 20:35
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 875
Location: Colombia
pelaillo
Vortex wrote:
What's wrong with the invoke macro?

Invoke macro contents is good. It's the name that I don't like.

Reasons:
1. I use "call" for every call: no need to diferentiate between APIs, procs with arguments, procs without arguments and normal labels.
2. I like small tabs and dislike to press more keys than needed.
3. It looks good, simpler and it works flawlessly.
4. It remembers me good old Tasm
5. I don't like anything that resembles Masm syntax Twisted Evil
Post 12 Sep 2004, 21:51
View user's profile Send private message Yahoo Messenger Reply with quote
silkodyssey



Joined: 02 Oct 2003
Posts: 205
Location: St.Vincent & the Grenadines
silkodyssey
Simple macro solution. Smile

Code:
macro call proc, [args]
{
    if ~args eq
       reverse push dword args
    end if
       common  call proc
}   
    

_________________
silkodyssey
Post 14 Sep 2004, 14:57
View user's profile Send private message MSN Messenger Reply with quote
Vortex



Joined: 17 Jun 2003
Posts: 335
Vortex
Silkodyssey, that is really an elegant solution Image

_________________
Code it... That's all...
Post 14 Sep 2004, 16:04
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 875
Location: Colombia
pelaillo
Yes, that is the integrated call proposed by KevinZheng here. To make your macro work in all given cases, you will need this:
Code:
macro call proc,[arg]
{
  reverse
        if   arg eq
 else
                pushd arg
   end if
  common
    if    defined API.#proc
   call [proc]
    else
     call proc
    end if
}
    

And define API.EveryFunction in the import macro.
Post 14 Sep 2004, 17:28
View user's profile Send private message Yahoo Messenger Reply with quote
silkodyssey



Joined: 02 Oct 2003
Posts: 205
Location: St.Vincent & the Grenadines
silkodyssey
pelaillo,

I'll try that code some time. At the moment I'm happy to just put the brackets around the api calls. Smile

_________________
silkodyssey
Post 14 Sep 2004, 22:42
View user's profile Send private message MSN Messenger 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-2019, Tomasz Grysztar.

Powered by rwasa.