flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > [solved] How to eliminate cinvoke

Author
Thread Post new topic Reply to topic
Picnic



Joined: 05 May 2007
Posts: 1281
Location: countryside
Picnic
Hi all,

I have a program in which i am using extensively msvcrt.inc functions.
To eliminate cinvoke i simply using fix directive.
Code:
strrchr fix cinvoke strrchr
strspn fix cinvoke strspn
strstr fix cinvoke strstr
...
    

But since include files are in the following form
Code:
strrchr,'strrchr',\
strspn,'strspn',\
strstr,'strstr',\ 
...
    

I thought that a macro could read the file line by line, copy each string between quotes and apply the fix directive to the new string, all at preprocessor stage.

p.s For now, all I've done is just to list functions, one by one.
Code:
macro fixall
{
      pos = 0
      virtual at pos
      file 'include\api\msvcrt.inc'
      len = $
      while ( pos < len )
        load c byte from pos
        if ( c = 39 )
          pos = pos + 1
          load c byte from pos
          while ( c <> 39 )
            display c          ; must concatenate letters to a new string
            pos = pos + 1
            load c byte from pos
          end while
          display 13,10      ; apply the fix directive to new string
        end if
        pos = pos + 1
      end while
      end virtual
}

fixall 
    

I don't know if this is possible, if so, i could really need some help.


Last edited by Picnic on 08 Sep 2012, 13:08; edited 1 time in total
Post 04 Aug 2012, 09:13
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
Don't use "fix" it has special function and should not be used for such things.
Use macro instead. IMHO, eliminating "cinvoke" is not a good idea. It will make the code less readable. Remember, Assembler is not HLL. Assembler has it's own syntax and writing style. If you like HLL style, better use C++.
Post 04 Aug 2012, 09:22
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Picnic



Joined: 05 May 2007
Posts: 1281
Location: countryside
Picnic
You're probably right, nevertheless i like to consider fasm as my programming language environment, not strictly as assembler and i enjoy having HLL style in asm.
Actually for me, code is less boring and more readable this way.

Anyway, can you please explain why using fix is wrong, you have some other way to eliminate cinvoke?


Last edited by Picnic on 04 Aug 2012, 11:34; edited 1 time in total
Post 04 Aug 2012, 11:14
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16903
Location: In your JS exploiting you and your system
revolution
Perhaps the question to answer here is why you want to eliminate cinvoke? If you can answer that then you might get more help from others once they realise the reason for it.


Last edited by revolution on 04 Aug 2012, 11:33; edited 1 time in total
Post 04 Aug 2012, 11:32
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
Code:
macro strrchr, [arg] {
common
  cinvoke strrchr, arg
}    
Post 04 Aug 2012, 11:33
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Picnic



Joined: 05 May 2007
Posts: 1281
Location: countryside
Picnic
JohnFound wrote:
Code:
macro strrchr, [arg] {
common
  cinvoke strrchr, arg
}    

Thanks for the snippet JohnFound.

revolution wrote:
Perhaps the question to answer here is why you want to eliminate cinvoke? If you can answer that then you might get more help from others once they realise the reason for it.

I am writing a program in which there is no other library in use other than msvcrt.
It's some kind of parser to handle text files exported in a specific form, from a commercial program we use at work.
The code looks much nicer without cinvoke.
Post 04 Aug 2012, 11:41
View user's profile Send private message Reply with quote
IceStudent



Joined: 19 Dec 2003
Posts: 60
Location: Ukraine
IceStudent
Post 06 Sep 2012, 11:29
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Picnic
First of all what you're trying to do is impossible. You said, you were trying to "fix" everything at the preprocessing stage, but at the same time you were only using the assembly stage directives.

Secondly, it's a mistake to take the name between the quotes, because what is actually used in the source is a label. And the label is the symbol before the quoted string.

Thirdly, I completely agree with JohnFound, that the fix directive is for the special purposes only.

Fourthly, your solution with fix could only work when defining the import table before "fixing". Otherwise such "fixing" would also replace label declarations with an uncompilable crap making the "fixed" functions useless.

Fifthly, what you actually need to do is the following:
Code:
macro api [args] {}
macro import lib,[label,string] { macro label [args] \{ \common cinvoke label,args \} }
include 'msvcrt.inc'
purge api,import

macro import [args]
{
     common
              macro purgelabels lib,[label,string] \{ \common purge label \}
         purgelabels args
            purge purgelabels
           import args
}    

After that you can call the msvcrt functions as follows:
Code:
strrchr mystr,','    
Post 07 Sep 2012, 20:02
View user's profile Send private message Reply with quote
Picnic



Joined: 05 May 2007
Posts: 1281
Location: countryside
Picnic
@IceStudent thanks for your reply.

@l_inc i just tried the code and works fine.
Correct me if i'm wrong, first you redefine api and import macros, and after you include the functions using the new import macro, you restore them, so simple...
Now, can you please explain what the second import macro does.
I noticed that if i ommit it, my program still compiles without the need for cinvoke.
Thank you.
Post 08 Sep 2012, 11:11
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Picnic
Quote:
first you redefine api and import macros, and after you include the functions using the new import macro, you restore them, so simple...

That's correct. I'm not sure, whether your msvcrt.inc contains an api-macro call. If it doesn't, than you don't need to redefine it.
Quote:
I noticed that if i ommit it, my program still compiles without the need for cinvoke.

That's probably because you define the import table before the provided macros. If you define the import table afterwards, the function labels will conflict with the macros as described in "fourthly", and the compilation will fail.

To prevent the conflict, the second import macro again makes use of the list of labels and undefines the macros, defined by the previous include 'msvcrt.inc'.
Post 08 Sep 2012, 12:16
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
[ Post removed by author. ]


Last edited by uart777 on 17 Nov 2013, 00:31; edited 1 time in total
Post 10 Sep 2012, 14:45
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1398
Location: Toronto, Canada
AsmGuru62
cinvoke is more readable than a group of PUSH-es and a CALL.
If a macro creates more readable code - it is a good macro.
If a macro hides a lot of code - it is not a good macro.

These above ^^^ are just my personal opinions.
I welcome everyone to contribute to FASM with whatever they can.
Post 10 Sep 2012, 16:23
View user's profile Send private message Send e-mail Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
[ Post removed by author. ]
Post 11 Sep 2012, 12:56
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-2019, Tomasz Grysztar.

Powered by rwasa.