flat assembler
Message board for the users of flat assembler.

Index > Main > flat assembler 1.66

Goto page 1, 2, 3  Next
Author
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
Not really much to say about this release: it's just a capstone of the 1.65 development line. See WHATSNEW.TXT for the summary.
Post 07 May 2006, 12:58
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
What in the plan for the 1.66 line Question , or are you going to take a vacation? Laughing
Post 07 May 2006, 20:20
View user's profile Send private message Reply with quote
shism2



Joined: 14 Sep 2005
Posts: 248
shism2
Tomasz I applaud your hardwork.. I wish I could see that " Fasm 2.0" you spoke about Wink
Post 08 May 2006, 03:27
View user's profile Send private message Reply with quote
dead_body



Joined: 21 Sep 2005
Posts: 187
Location: Ukraine,Kharkov
dead_body
Tomasz, and what about doing a returning value from macros?
like a example:
Code:
macro $invoke func,[args]
{
invoke func,args
exitm eax
}
mov edi,$invoke GetModuleHandle,0
    

i know that it can be done, like:
macro mov p1,p2 .... match ....
but it is too difficult, and with return value I can write:
Code:
xor edi,$invoke AnyAPI,1,2,3
xchg edi,$invoke AnyAPI,1,2,3
    

and not to do:
macro xor
macro xchg
and so with each instruction.

1.66 fasm is really great. Good Work!
Post 08 May 2006, 07:36
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
EXITM is completely incompatible with how macros work in fasm 1.x, sorry. Maybe in 2.0 Wink
Post 08 May 2006, 11:20
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
It would certainly be a welcome addition - and not just for highlevel style stuff like dead_body posted.

_________________
Image - carpe noctem
Post 08 May 2006, 15:57
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
As I said, it cannot just be "added". But there would be a macro system written differently that would allow this.
For fasm 1.xx macro is like directive, and thus it always spans the entire line (not counting the optional initial labels). Also, the macro puts the new lines AFTER the line that invokes it (while with inline-allowing macro systems it has to be the opposite).
Post 08 May 2006, 16:44
View user's profile Send private message Visit poster's website Reply with quote
shism2



Joined: 14 Sep 2005
Posts: 248
shism2
That return value macro would be very USEFUL WOW
Post 08 May 2006, 22:47
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
I think inline macros would be mach too confusing. You guys seem to want FASM code to start looking like C. You can always do this:
Code:
macro abc returnvar,[params] {
...
returnvar equ eax
}

abc retval,1,2,3,4
mov edi,retval    
Post 08 May 2006, 23:58
View user's profile Send private message Visit poster's website Reply with quote
shism2



Joined: 14 Sep 2005
Posts: 248
shism2
?? That didnt do anything..
Post 09 May 2006, 00:18
View user's profile Send private message Reply with quote
dead_body



Joined: 21 Sep 2005
Posts: 187
Location: Ukraine,Kharkov
dead_body
But why simply not to add extended macro, from "versions 2.0"(Simply there is no need do two versions, this will be a schism.)

macro_ex - for instance. And he will be able to return value.

macro_ex will be processed apart, in any part of the line.
He will be able to return the line.
for instance:

Code:
macro_ex $invoke func,[args] 
{ 
invoke func,args
exitm eax 
}
 mov edi,$invoke GetModuleHandle,0
;here be:
invoke GetModuleHandle,0
mov edi,eax
;but if macro was such:
macro_ex $invoke func,[args] 
{ 
exitm eax 
invoke func,args
}
;that was got:
mov edi,eax
invoke GetModuleHandle,0    


simply here is there is a preprocessor and an assembler, but be else added as it were assembler2, which and processed macro_ex.
Post 09 May 2006, 07:57
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
Version 2.0 would have completely different architecture from 1.x, if I ever write it. I already have much of its design in my head, but there are still some important problems that keep my far from considering such project right now.
As for 1.x, I would prefer to not add any new directives at this stage. There's already enough mess with the existing ones.
Post 09 May 2006, 12:12
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: 4633
Location: Argentina
LocoDelAssembly
Tomasz Grysztar wrote:
Version 2.0 would have completely different architecture from 1.x, if I ever write it


If not please don't forget to publish your desing ideas when you decide stop working on FASM.

BTW, maybe is a good idea that someone else start writing an extended preprocesor which output is compatible with the current version of FASM, in that way lot of things can be tested before actually including it on FASM 2.

Regards
Post 09 May 2006, 13:18
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
The main idea for fasm 2 is that there would be no preprocessor. Symbolic variables and macroinstructions would be processed by assembler, being affected by code-resolving, and - perhaps for symbolic variables - with option to be forward referenced.
The other of main ideas is the common symbol recognition routine that would classify any known symbol or allocate some common-format data structure for the new one. And this data structure would cover not only labels and numeric assembly-time variables, as it does now, but also symbolic variables, macros, etc.
Post 09 May 2006, 14:23
View user's profile Send private message Visit poster's website Reply with quote
Aster!x



Joined: 16 Jul 2004
Posts: 26
Aster!x
in masm
Code:
$invoke MACRO vars:VARARG
     invoke vars
     EXITM <eax>
ENDM    

and usage like this
Code:
mov hInstance, $invoke(GetModuleHandle, NULL)    

Something similar in fasm would be good
Post 09 May 2006, 19:09
View user's profile Send private message Reply with quote
dead_body



Joined: 21 Sep 2005
Posts: 187
Location: Ukraine,Kharkov
dead_body
to asterix:
read my previous post, and replay to it.
Maybe in fasm 2.0
Post 09 May 2006, 19:47
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
dead body: inline macros would be implementable in currect FASM logic. but there are still few problems, after i finish my thinking about it i will give final idea to tomasz. Wink. Problem is that some things can be done easily in MASM and cannot be done at all in FASM, even some usuable things. because of this, FASM wasn't used for one very very interesting project. sorry, i don't know if i can tell more...

so my conclusion to 0xDEADB0D7: let it be for now, or mail/ICQ me, there are some problems that need to be solved before idea is complete.
Post 09 May 2006, 20:25
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
dead_body



Joined: 21 Sep 2005
Posts: 187
Location: Ukraine,Kharkov
dead_body
vid wrote:
dead body: inline macros would be implementable in currect FASM logic.


It is good news. May you will give some examples?
Post 11 May 2006, 17:33
View user's profile Send private message Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 975
Location: Czechoslovakia
MazeGen
I second that. Could you public your thoughs?
Post 12 May 2006, 10:17
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
from my point of view, there are 2 main problems: usage and processing priority.

About usage - how would you specify it's arguments. FASM uses '(' and ')' for other purposes,
Processing - what exact priority should it's use have? I am not really sure if this would be really a problem, i never used these in MASM.

Also adding new feature language seems like a problem to me, fasm is anyway becoming too overfeatured, losing one of it's main advantages. Do we really need that much power? (hint: look at emacs)

All other things doesn't seems to be a problem to me
Post 12 May 2006, 11:18
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2, 3  Next

< 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-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.