flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > if 0 include opens file and modifies current label [fixed]

Author
Thread Post new topic Reply to topic
cod3b453



Joined: 25 Aug 2004
Posts: 618
cod3b453 17 Aug 2013, 13:12
I'm not sure to what extent this is a bug but it certainly kept me guessing for a while until I narrowed it down:

test.asm
Code:
        some_var = 0

a_label:

        jmp .sublabel

if some_var = 1

        include 'test2.asm'

end if

        .sublabel:       
test2.asm
Code:
        display 'This should not be opened'

        another_label:

        err 'This should not be built'
                                                       
It looks like FASM opens test2.asm, which I hadn't expected, but does not perform any evaluation other than updatng the current label, which results in jmp .sublabel failing. As shown above, other constructs appear to have no effect in test2.asm; only the jmp is assembled if another_label is removed.


Last edited by cod3b453 on 17 Aug 2013, 15:10; edited 1 time in total
Post 17 Aug 2013, 13:12
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 17 Aug 2013, 13:36
It is not a bug. Cool

You have to distinct between conditional assembly and conditional preprocessing.

if directive is conditional assembly and will interpreted during assembler phase only.

include is preprocessing directive and is done before if directive is interpreted.

You have to use match directive for conditional preprocessing.

Code:
SOME_VAR EQU YES
match =YES,SOME_VAR {
  ...
}
match =SOME_VAR,SOME_VAR {
  ...
}
    

See documentation for more details.
The last one is useful to handle cases where SOME_VAR is not set at all.
Post 17 Aug 2013, 13:36
View user's profile Send private message Send e-mail Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 618
cod3b453 17 Aug 2013, 15:13
bah! Embarassed, thank you shutdownall Cool

Half of my problem was using x = 0 instead of x equ 0...time to rewrite some macros Laughing
Post 17 Aug 2013, 15:13
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 17 Aug 2013, 20:31
shutdownall wrote:
It is not a bug.
I disagree. Probably fasm handles labels too early (I'm going to examine sources, but not too soon). Consider the following:
Code:
if 0
  \1:
end if
.1:
rb 16; make some noise
\.1 = .1; make it accessible inside '\1' scope
\1 dw \.1, \1.1
.1:    
One could expect that it will compile, but it doesn't. Next one compiles fine:
Code:
rept 0 {
  \1:
}
.1:
rb 16; make some noise
\.1 = .1; make it accessible inside '\1' scope
\1 dw \.1, \1.1
.1:    
As a side note, presence of SOME_VAR equ SOME_VAR is indistinguishable from its absense. Wink

----8<----
Tomasz Grysztar,

Would you please entab/detab sources consistently? 1.71.00 (spaced) => 1.71.01 (tabbed) => 1.71.06 (spaced) => 1.71.07 (tabbed); this is based on ASSEMBLE.INC, other files reveal different patterns. Wink
Post 17 Aug 2013, 20:31
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 19 Aug 2013, 00:56
baldr wrote:
shutdownall wrote:
It is not a bug.
I disagree. Probably fasm handles labels too early (I'm going to examine sources, but not too soon).


I know how FASM works as I did build up a lot of things to change the compiling process and results when integrating my BASIC commands and structure.

There are done following 4 steps (in this order):

<PREPROCESS>
<PARSE>
<ASSEMBLE>
<FORMAT>

During PREPROCESS labels are not touched or examined at all.
So what is too early in your eyes ?
Labels are determined in ASSEMBLE process only in several passes if necessary. They can not determined during PREPROCESS and not during PARSE because the resulting code (and its size) can be determined during ASSEMBLE only.


baldr wrote:
As a side note, presence of SOME_VAR equ SOME_VAR is indistinguishable from its absense. Wink


Yes but as there is no default match this is a workaround to determine a forgotten SOME_VAR directive. Even SOME_VAR EQU BAD doesn't find a match representation. If you know the size of inserted code for example you can work with labels and check the code size.

Look at following code piece which checks if a variable is inserted at all (CDFLAG) to have a default handling. Could be done with a "label calculation" and assert as well:

Code:
match =FAST_MODE,STARTMODE {
        CDFLAG  db FAST_MODE
}
match =SLOW_MODE,STARTMODE {
        CDFLAG  db SLOW_MODE
}
match =STARTMODE,STARTMODE {
        CDFLAG  db SLOW_MODE
}
        assert  CDFLAG > -1
    
Post 19 Aug 2013, 00:56
View user's profile Send private message Send e-mail Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 19 Aug 2013, 01:03
cod3b453 wrote:
As shown above, other constructs appear to have no effect in test2.asm; only the jmp is assembled if another_label is removed.


Well look at your sample in the first posting.
The reason why the jump fails is simple.
You make a jump to a local label 'sublabel'.
This is valid in the own context 'a_label'.

If you include your code, a new main label 'another_label' is defined and so 'sublabel' becomes a sub label of 'another_label'.
That's the trick.

But you can still jump to this label from the other code with jmp another_label.sublabel for example. But it is not a good coding style to include another file in this main label routine. At the end of 'a_label' would be a nicer place, don't you think so ?
Post 19 Aug 2013, 01:03
View user's profile Send private message Send e-mail Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 19 Aug 2013, 01:07
baldr wrote:
Consider the following:
Code:
if 0
  \1:
end if
.1:
rb 16; make some noise
\.1 = .1; make it accessible inside '\1' scope
\1 dw \.1, \1.1
.1:    
One could expect that it will compile, but it doesn't. Next one compiles fine:
Code:
rept 0 {
  \1:
}
.1:
rb 16; make some noise
\.1 = .1; make it accessible inside '\1' scope
\1 dw \.1, \1.1
.1:    


Well - in my eyes this is simply brainfucking. Have fun with this coding style. Wink
Post 19 Aug 2013, 01:07
View user's profile Send private message Send e-mail Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 618
cod3b453 19 Aug 2013, 16:46
shutdownall wrote:
cod3b453 wrote:
As shown above, other constructs appear to have no effect in test2.asm; only the jmp is assembled if another_label is removed.


Well look at your sample in the first posting.
The reason why the jump fails is simple.
You make a jump to a local label 'sublabel'.
This is valid in the own context 'a_label'.

If you include your code, a new main label 'another_label' is defined and so 'sublabel' becomes a sub label of 'another_label'.
That's the trick.

But you can still jump to this label from the other code with jmp another_label.sublabel for example. But it is not a good coding style to include another file in this main label routine. At the end of 'a_label' would be a nicer place, don't you think so ?
I haven't argued to the contrary; as we already know, I got precedence wrong. Confused
Post 19 Aug 2013, 16:46
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 19 Aug 2013, 17:12
Was just a clarification. Wink
Post 19 Aug 2013, 17:12
View user's profile Send private message Send e-mail 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-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.