Index
> Main > flat assembler 1.66Goto page 1, 2, 3 Next |
| Author |
|
|
Tomasz Grysztar 07 May 2006, 12:58
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.
|
|||
07 May 2006, 12:58 |
|
|
madmatt 07 May 2006, 20:20
What in the plan for the 1.66 line
 , or are you going to take a vacation?  |
|||
|
07 May 2006, 20:20 |
|
|
shism2 08 May 2006, 03:27
Tomasz I applaud your hardwork.. I wish I could see that " Fasm 2.0" you spoke about
 |
|||
|
08 May 2006, 03:27 |
|
|
Tomasz Grysztar 08 May 2006, 11:20
EXITM is completely incompatible with how macros work in fasm 1.x, sorry. Maybe in 2.0
|
|||
|
08 May 2006, 11:20 |
|
|
f0dder 08 May 2006, 15:57
It would certainly be a welcome addition - and not just for highlevel style stuff like dead_body posted.
_________________  - carpe noctem |
|||
|
08 May 2006, 15:57 |
|
|
Tomasz Grysztar 08 May 2006, 16:44
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). |
|||
|
08 May 2006, 16:44 |
|
|
shism2 08 May 2006, 22:47
That return value macro would be very USEFUL WOW
|
|||
|
08 May 2006, 22:47 |
|
|
revolution 08 May 2006, 23:58
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 |
|||
|
08 May 2006, 23:58 |
|
|
shism2 09 May 2006, 00:18
?? That didnt do anything..
|
|||
|
09 May 2006, 00:18 |
|
|
dead_body 09 May 2006, 07:57
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. |
|||
|
09 May 2006, 07:57 |
|
|
Tomasz Grysztar 09 May 2006, 12:12
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. |
|||
|
09 May 2006, 12:12 |
|
|
LocoDelAssembly 09 May 2006, 13:18
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 |
|||
|
09 May 2006, 13:18 |
|
|
Tomasz Grysztar 09 May 2006, 14:23
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. |
|||
|
09 May 2006, 14:23 |
|
|
Aster!x 09 May 2006, 19:09
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 |
|||
|
09 May 2006, 19:09 |
|
|
dead_body 09 May 2006, 19:47
to asterix:
read my previous post, and replay to it. Maybe in fasm 2.0 |
|||
|
09 May 2006, 19:47 |
|
|
vid 09 May 2006, 20:25
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.
. 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. |
|||
|
09 May 2006, 20:25 |
|
|
dead_body 11 May 2006, 17:33
vid wrote: dead body: inline macros would be implementable in currect FASM logic. It is good news. May you will give some examples? |
|||
|
11 May 2006, 17:33 |
|
|
MazeGen 12 May 2006, 10:17
I second that. Could you public your thoughs?
|
|||
|
12 May 2006, 10:17 |
|
|
vid 12 May 2006, 11:18
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 |
|||
|
12 May 2006, 11:18 |
|
| Goto page 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|