flat assembler
Message board for the users of flat assembler.

Index > Main > flat assembler 1.71.23

Goto page Previous  1, 2, 3, 4  Next
Author
Thread Post new topic Reply to topic
system error



Joined: 01 Sep 2013
Posts: 670
system error 03 Nov 2014, 15:05
revolution wrote:
At least it is clear what they are. And BTW A386 was an awful assembler with an equally awful author.

I don't get the connection there. I may or may not be a "soccer mom", but how does that relate to liking milk?


I don't care about A386. You are a soccer mom. Admit it. Fasm-junior?? gosh, Does it have to be that obvious? Twisted Evil
Post 03 Nov 2014, 15:05
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system
revolution 03 Nov 2014, 15:16
system error wrote:
You are a soccer mom. Admit it. Fasm-junior?? gosh, Does it have to be that obvious? Twisted Evil
That wiki pedium thing wrote:
The phrase soccer mom broadly refers to a North American middle-class suburban woman who spends a significant amount of her time transporting her school-age children to their youth sporting events or other activities.
I still don't get the milk connection there.
Post 03 Nov 2014, 15:16
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 670
system error 03 Nov 2014, 15:24
That wiki pedium thing wrote:
The phrase soccer mom broadly refers to a North American middle-class suburban woman who spends a significant amount of her time transporting her school-age children to their youth sporting events or other activities.


...goes with "fasm-junior" Laughing

You are a woman/girl revo. I think I can confirm this with sid123 (where's that guy anyway?)
Post 03 Nov 2014, 15:24
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22 03 Nov 2014, 17:11
The proper name for a FASM version that relies solely on its macro language to get work done would be
Quote:
FASM-NP-Hard
Post 03 Nov 2014, 17:11
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland
Tomasz Grysztar 03 Nov 2014, 19:02
l_inc wrote:
I can't follow the logic. The inequality signs should create a processing context, in which commata are not interpreted as argument separators. This would be pretty much like passing arguments through the (Windows) command line: (...)
If "<"/">" suppressing the comma recognition were allowed in any place inside the argument, the problem would arise whether they should be removed from the value or stay there. Currently only the enclosing ones are not a part of the value (the "enclosed" word suggests it). All the "<" and ">" characters inside stay being a part of the value, it is only required that they are paired (this is the part that is not detailed correctly in the manual). In your example of command line the quotes placed anywhere do not become a part of value, they are always just the control characters - and this is the difference. Treating the outer enclosing "<" and ">" in a different way than the ones inside is needed for the purposes of nesting.
Post 03 Nov 2014, 19:02
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 03 Nov 2014, 19:48
Tomasz Grysztar
Quote:
the problem would arise whether they should be removed from the value or stay there

For this reason I tried to be explicit by suggesting to eliminate only the outer (but not necessarily the bordering) matching pairs when passing the argument value to a single-argument processing code. This allows to pass all inner inequality signs as is, if necessary.

Quote:
In your example of command line the quotes placed anywhere do not become a part of value, they are always just the control characters

Not really. They can be shielded by backslashes and this way become a part of an argument. In case of fasm macro argument passing an additional shielding character is not necessary, because indicating the beginning and the ending of a macro argument is done with different characters, as opposed to the single quotation mark character used for enclosing command line arguments with spaces.

Quote:
Treating the outer enclosing "<" and ">" in a different way than the ones inside is needed for the purposes of nesting

Outer but not necessarily enclosing.

But I see, that allowing to eliminate the enclosing "<" and ">" only is the simplest interface. Allowing the elimination at arbitrary argument locations creates many ambiguous situations, that would have to be explicitly ruled out in the documentation. I just wanted to solve the problem of passing arbitrary symbol sequences to the common block, but it seems that the new ampersand feature is still a better solution.

_________________
Faith is a superposition of knowledge and fallacy
Post 03 Nov 2014, 19:48
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 06 Nov 2014, 08:45
fasm is an assembler, leave it be as such. Wink
Post 06 Nov 2014, 08:45
View user's profile Send private message Reply with quote
ACP



Joined: 23 Sep 2006
Posts: 204
ACP 09 Nov 2014, 23:04
baldr wrote:
fasm is an assembler, leave it be as such. Wink

Can't agree more. This is what I like about FASM and this is the reason why I'm using it still - just like I did with A86 and TASM in the past.
Post 09 Nov 2014, 23:04
View user's profile Send private message Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1166
Location: Overflow
Matrix 10 Nov 2014, 05:55
ACP wrote:
baldr wrote:
fasm is an assembler, leave it be as such. Wink

Can't agree more. This is what I like about FASM and this is the reason why I'm using it still - just like I did with A86 and TASM in the past.


I think you will have Fasm 1.0 final version soon, you know, if something is perfect it does not need fixing Wink

Then Tomasz starts to develop his macronizer tool.
Post 10 Nov 2014, 05:55
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 10 Jan 2015, 01:44
Tomasz Grysztar
Would there be any motivation presented for the latest equality colonization (or colon equalization) extension?

_________________
Faith is a superposition of knowledge and fallacy
Post 10 Jan 2015, 01:44
View user's profile Send private message Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 767
tthsqe 10 Jan 2015, 04:37
Is it possible to get the preprosessor to evaluate expressions?
Post 10 Jan 2015, 04:37
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system
revolution 10 Jan 2015, 05:20
tthsqe wrote:
Is it possible to get the preprosessor to evaluate expressions?
Yes. With rept.
Post 10 Jan 2015, 05:20
View user's profile Send private message Visit poster's website Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 767
tthsqe 10 Jan 2015, 06:44
please elaborate. I know that if i switch to a+b=c in the example, it is now evaluated by the assembler, not the preprocessor.
Code:
macro foo a, b, c {
 if a+b eq c
  err
 end if
}

foo 1,1,2 ; does not causes error
foo 1,1,1+1 ; causes error    

How to make both foo calls err?

Edit: ah, just found it in the documentation.

Code:
macro eval x, expr {
local X
 rept 1 X:expr \{ define x X \}
}

macro foo a, b, c {
local x, y
 eval x, a+b
 eval y, c
 if x eq y
  err
 end if
}

; both of these err
foo 1,1,1+1
foo 1,1,2    


May I verify that only the preprocessor is being used to generate the err directive?
Post 10 Jan 2015, 06:44
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 10 Jan 2015, 14:39
tthsqe
Quote:
I know that if i switch to a+b=c in the example, it is now evaluated by the assembler, not the preprocessor

In your example the condition is not evaluated by the preprocessor either. If you look into the manual the only macroinstruction for conditional preprocessing is match. The repeating macroinstructions can be used for conditional preprocessing for some specific cases as well.

Quote:
How to make both foo calls err?

eq is a different kind of comparison. Consult the manual for details, but for your current task it's not what you need.

Quote:
May I verify that only the preprocessor is being used to generate the err directive?

For a plausible verification you should do something preprocessor related inside your condition. The simplest thing to do would be to generate a preprocessing error: irp{} . But there is a plenty of other ways. E.g. redefine an existing macro and then invoke it unconditionally afterwards.

_________________
Faith is a superposition of knowledge and fallacy
Post 10 Jan 2015, 14:39
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland
Tomasz Grysztar 10 Jan 2015, 14:43
l_inc wrote:
Tomasz Grysztar
Would there be any motivation presented for the latest equality colonization (or colon equalization) extension?
I initially implemented it with "=" without giving much thought to it, simply because this was the syntax suggested in request, but now I think that the syntax would a bit more uniform if there was ":" used for this purpose as it is with parameters for REPT directive. I'm not going to remove the legacy syntax (if I wanted to do it, I really should have done it before it left the "experimental" phase), but I may try to personally promote use of ":" for this purpose in the future.
Post 10 Jan 2015, 14:43
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 10 Jan 2015, 14:52
Tomasz Grysztar
So it's syntax unification with respect to the rept directive. But still rept isn't allowed to use the equality sign.

_________________
Faith is a superposition of knowledge and fallacy
Post 10 Jan 2015, 14:52
View user's profile Send private message Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 767
tthsqe 10 Jan 2015, 17:49
I_inc you response has disappointed me because I though I knew what was going on.
So for
Code:
macro eval x, expr { 
local X 
 rept 1 X:expr \{ define x X \} 
} 

macro foo a, b, c { 
local x, y 
 eval x, a+b 
 eval y, c 
 if x eq y 
  err 
 end if 
} 

; both of these err 
foo 1,1,1+1 
foo 1,1,2    

can you tell me exactly what gets passed along to the assembler?
Post 10 Jan 2015, 17:49
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 10 Jan 2015, 20:34
tthsqe
I guess at this point I'm supposed to show you a fishing rod. Which is the "prepsrc" tool in the tools subdirectory of the fasm package. To see what you get after preprocessing you should do something like this:
Code:
fasm.exe -m 1572864 -s  "mysource.fas" "mysource.asm"
prepsrc.exe "mysource.fas" "mysource_p.asm"    

"mysource_p.asm" will then contain what gets passed to the assembler and all the steps of preprocessing.

It could be possible however that your goal is performance related. Then you'd need to know that eq is evaluated at the parsing stage of the assembler. I.e. if you have such a condition in a loop, then you won't experience the related performance penalty for its evaluation:
Code:
repeat $1000000
    if 1+1 eq 2
        
    end if
end repeat    

The code above currently compiles significantly faster then the code below.
Code:
repeat $1000000
    if 0
        
    end if
end repeat    

_________________
Faith is a superposition of knowledge and fallacy
Post 10 Jan 2015, 20:34
View user's profile Send private message Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 767
tthsqe 10 Jan 2015, 23:07
Ok, Thanks, I did not know about that. I hope to answer the following questions:
- is the output of eq always a 0 or a 1?
- how to get the prepocessor to not even bass a block of code to the assembler?

Edit:
I_inc: I think I got it! (is this the best way to do this?)
Code:
; set x to be the evaluation expr
macro eval x, expr {
local X  
 rept 1 X:expr \{ x equ X \}
}

macro foo a, b, c {
local x
 eval x, (a)+(b)-(c)
 match =0, x \{
  err  
 \}
}  

; both of these err just from preprocessor 
foo 1,1,1+1  
foo 1,1,2    
Post 10 Jan 2015, 23:07
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 11 Jan 2015, 03:15
tthsqe
This is a possible way. You could simplify it, so that you don't need additional symbols (x and X). local X in your eval macro is pointless anyway.

Additionally, as I said before, sometimes you can make repeating macroinstructions get your conditional preprocessing work as you need it. For example,
Code:
macro foo a, b, c { rept ((a)+(b)-(c)-1)and $FFFFFFFF/$FFFFFFFF \{ display 'a+b=c',13,10 \} }    

_________________
Faith is a superposition of knowledge and fallacy
Post 11 Jan 2015, 03:15
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4  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-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.