conditional assembly

Index > Compiler Internals > conditional assembly

Author

Thread

shutdownall

Joined: 02 Apr 2010
Posts: 517
Location: Munich

shutdownall 15 Mar 2012, 22:26

Hmm I tried to use conditional assembly with match but that does not work.
Maybe I did not understood the examples.
Tried:

Code:

DFILETYPE EQU EXPANDED

match =DFILETYPE,COLLAPSED {
                        db 3 dup(NEWLINE)
                        db $28,$37,$2A,$26,$39,$2A,$29,0,$3C,$2E,$39,$2D,0,$3F,$3D,$24,$1D,$16,$2E,$29,$2A
                        db 22 dup(NEWLINE)
}
match =DFILETYPE,EXPANDED {
                         db NEWLINE
                         repeat 24
                         db 32 dup(SPACE),NEWLINE
                         end repeat
}

In this configuration both blocks are assembled.
I tried first without = but than none of the blocks are assembled.

So what is the best way for conditional assembly ?
[/quote]

15 Mar 2012, 22:26

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland

Tomasz Grysztar 15 Mar 2012, 22:31

The symbolic variables are replaced with their values in the expression on the right sight of the comma, not on the left side (that is: not in the matching pattern). So you should use "match =COLLAPSED,DFILETYPE" instead of "match =DFILETYPE,COLLAPSED", etc.

15 Mar 2012, 22:31

shutdownall

Joined: 02 Apr 2010
Posts: 517
Location: Munich

shutdownall 15 Mar 2012, 22:36

Thanks, I didn't expect it this way.
Is not logical for me, that only one side (left or right) is replaced. But I take it like it is, it works now. Very Happy

15 Mar 2012, 22:36

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland

Tomasz Grysztar 15 Mar 2012, 23:07

The lines containing preprocessor directives in general do not have symbolic variables replaced with their values, the directives have higher priority of processing (see section 2.3.7 of manual). The right side of "match" expression is one of special cases.

And please look here: http://board.flatassembler.net/topic.php?p=34035#34035
for a more detailed explanation.

15 Mar 2012, 23:07

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 15 Mar 2012, 23:16

shutdownall
First of all, you should clearly distinguish conditional assembly and conditional preprocessing. match is a conditional preprocessing directive.

Secondly, every macro-block (macro, struc, match, rept, irp, irps) has a phase of replacing it's arguments within it's body. The arguments are only meaningful in the context of the macro-block, so they are never replaced (with one exception of the fix directive) by the outside values. That's the logic behind the replacing. Otherwise there would be a lot of problems when choosing argument names for macros. E.g. the following code would not compile (you can check this by replacing equ with fix):

Code:

string equ "my_global_string"

macro show string { display string,13,10 }

show "Message"

Btw. that's also a reason to use the fix directive only in absolutely_necessary_cases.

The symbols on the left side of the match directive's comma, that are not compared literally, are a kind of the match macro-block arguments, that get the values of the symbols on the right side. Replacing the literally matching symbols on the left side would also break many expectations.

15 Mar 2012, 23:16

shutdownall

Joined: 02 Apr 2010
Posts: 517
Location: Munich

shutdownall 15 Mar 2012, 23:42

l_inc wrote:

shutdownall
First of all, you should clearly distinguish conditional assembly and conditional preprocessing. match is a conditional preprocessing directive.

In that point I can say that conditional preprocessing in this way can be used for conditional assembly because preprocessor gives one of the blocks (only one) to be assembled. And that is exactly what I need and wanted.

So if you NEED conditional assembly this is a good (maybe not the only) way to realize. That's why the topic conditional assembly is correct even if the preprocessor does the work. I define a condition under which a block is assembled or not - that's it. Wink

15 Mar 2012, 23:42

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 16 Mar 2012, 00:01

shutdownall
I just wanted to point out the crucial difference between those terms. If the difference is clear to you I still suggest you to use the common definitions provided by the documentation (rather than introduce your own) in order to avoid misunderstanding.

Quote:

So if you NEED conditional assembly this is a good (maybe not the only) way to realize.

Whether it's a valid way to implement conditional assembly, depends on the desired condition. It's not just a bad, but an invalid way to check assembly time variables with the conditional preprocessing directive.

16 Mar 2012, 00:01

shutdownall

Joined: 02 Apr 2010
Posts: 517
Location: Munich

shutdownall 16 Mar 2012, 21:18

l_inc wrote:

I still suggest you to use the common definitions provided by the documentation (rather than introduce your own) in order to avoid misunderstanding.

Maybe you better point this out because I have no idea what you mean exactly.

l_inc wrote:

Whether it's a valid way to implement conditional assembly, depends on the desired condition. It's not just a bad, but an invalid way to check assembly time variables with the conditional preprocessing directive.

I did not use variables, I used symbolic constants which are listed in documentation in the preprocess section 2.3.2. Tomasz pointed out some examples of conditional preprocessing which effects naturally assembling.

Quote:

match directive causes some block of source to be preprocessed AND passed to assembler only when the given sequence of symbols matches the specified pattern.

http://flatassembler.net/docs.php?article=manual#2.3.6

So I can not find why this should be bad or invalid ? Rolling Eyes

16 Mar 2012, 21:18

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 17 Mar 2012, 14:38

shutdownall

Quote:

Maybe you better point this out because I have no idea what you mean exactly.

Assume you have two different source files. You're going to compile one of them depending on whether it's raining now (you're free to choose a more realistic dependency). Would that be conditional assembly? Because that's exactly what happens with match: the assembler compiles unconditionally, what it got after the preprocessing stage.

You surely can use a more general definition of conditional assembly, but then the reader of your message would think, that you don't have a basic understanding of the fasm operation, as it happened to me when reading the phrase: "I tried to use conditional assembly with match but that does not work".

Quote:

I did not use variables, I used symbolic constants which are listed in documentation in the preprocess section 2.3.2.

My comment is related to your general statement: "So if you NEED conditional assembly this is a good (maybe not the only) way to realize" — rather than to your code.

Quote:

So I can not find why this should be bad or invalid ?

Provided citation discusses preprocessing stage symbols. I talked about assembly stage values.

Last edited by l_inc on 17 Mar 2012, 16:53; edited 1 time in total

17 Mar 2012, 14:38

shutdownall

Joined: 02 Apr 2010
Posts: 517
Location: Munich

shutdownall 17 Mar 2012, 15:06

You must be very convinced about yourself. Rolling Eyes

Why not develop your own assembler as you discuss and complain features and implementations used by FASM in all your other threads ?

17 Mar 2012, 15:06

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 17 Mar 2012, 16:53

shutdownall

Quote:

You must be very convinced about yourself.

I'm always open to persuasion with reasonable argumentation.

Quote:

Why not develop your own assembler as you discuss and complain features and implementations used by FASM in all your other threads?

I love fasm. The reason of those complaints is that I want it to be even better. In particular, I wanna have indisputable arguments, when trying to convince someone, that fasm is the best. However you won't see me in such discussions in this forum, because local members are already attracted by fasm.

17 Mar 2012, 16:53

< 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