flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > [fasmg] conditional assembly

Author
Thread Post new topic Reply to topic
sylware



Joined: 23 Oct 2020
Posts: 57
Location: Marseille/France
sylware
Hi,

I am setting up preliminary OS abstraction to my program using conditional assembly:
Code:
; default
if ~defined LINUX_GLIBC
    define LINUX_GLIBC 1
end if

if LINUX_GLIBC
   display 'blahblah',0x0a
end if
    


This fails to assemble, what do I miss?
Post 16 Aug 2021, 12:45
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18181
Location: In your JS exploiting you and your system
revolution
This is the standard oscillating problem.

At line 2, the if
Pass 1: LINUX_GLIBC not defined, so it gets defined for the next pass.
Pass 2: LINUX_GLIBC is defined so it never gets defined for the next pass.
Pass 3: Same as pass 1.
Pass 4: Same as pass 2.
etc...

See the link for more detail and explanation.
Post 16 Aug 2021, 12:57
View user's profile Send private message Visit poster's website Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 57
Location: Marseille/France
sylware
Ok, I have to keep in mind this multi-pass oscillating thingy then.

I guess I need to write "pass idempotent" configuration instructions.
Post 16 Aug 2021, 13:36
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3290
Location: vpcmipstrm
bitRAKE
The trick ...
Code:
; define LINUX_GLIBC 0 ; test

if ~defined LINUX_GLIBC
    restore LINUX_GLIBC
    define LINUX_GLIBC 1
end if

; or this works too ...
;match =LINUX_GLIBC,LINUX_GLIBC
;    restore LINUX_GLIBC
;    define LINUX_GLIBC 1
;end match

if LINUX_GLIBC
   display 'blahblah',0x0a
end if    
This has the effect of turning off forward references for the symbol - because the value changes.

_________________
¯\(°_o)/¯ unlicense.org
Post 16 Aug 2021, 14:05
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3290
Location: vpcmipstrm
bitRAKE
Here is another way ...
Code:
;define LINUX_XLIBC 0 ; test

if defined LINUX_XLIBC & LINUX_XLIBC < __LINE__
else
        LINUX_XLIBC equ __LINE__
end if

if LINUX_XLIBC
        display 'value > 0',10
end if    
Very Happy (This might be a bug, but I am not going to say anything. Then again it might be because __LINE__ is a variable. Works with other variable terms like $, too.)
Post 16 Aug 2021, 14:25
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7925
Location: Kraków, Poland
Tomasz Grysztar
There is a thread about the pitfalls of "optimistic" multi-pass assembly, where I attempted to explain why such problems happen and how to deal with them.

The solution using RESTORE works because the use of this directive disables forward-reference on that variable. But the recommended method would be to just use DEFINITE operator instead of DEFINED, since DEFINITE directly implies that forward references should not be used.

However, for DEFINITE to work correctly there, it should be used with symbol defined numerically, with directives like "=", not DEFINE/EQU, because symbolic substitutions happen before the IF condition is evaluated. If you do "define LINUX_GLIBC 1", then "if ~ defined LINUX_GLIBC" becomes "if ~ defined 1" through text substitution and is evaluated as such. A better option would then be to make it "LINUX_GLIBC := 1" and "if ~ definite LINUX_GLIBC".
Post 16 Aug 2021, 16:49
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7925
Location: Kraków, Poland
Tomasz Grysztar
bitRAKE wrote:
(This might be a bug, but I am not going to say anything. Then again it might be because __LINE__ is a variable. Works with other variable terms like $, too.)
It's not because of a variability, it works with a constant just as well:
Code:
;define LINUX_XLIBC 0 ; test

if defined LINUX_XLIBC & LINUX_XLIBC < 1
else
        LINUX_XLIBC equ 1
end if

if LINUX_XLIBC
        display 'value > 0',10
end if    
If you look at the logic of this source text, the only way for it to not be self-contradictory is when the ELSE route is taken. This is a valid (consistent) solution and fasmg is able to find it.
Post 16 Aug 2021, 16:49
View user's profile Send private message Visit poster's website Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 57
Location: Marseille/France
sylware
It seems the less convoluted way to work with multi-pass assembly for this to work is to use ":=" and "definite".

Or maybe there is a more elegant and "fasmg way" to acheive this?
Post 18 Aug 2021, 13:58
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3290
Location: vpcmipstrm
bitRAKE
Tomasz Grysztar wrote:
the recommended method would be to just use DEFINITE operator instead of DEFINED, since DEFINITE directly implies that forward references should not be used.
Even in non-numerical situations a numerical flag could be set and used with DEFINITE.

_________________
¯\(°_o)/¯ unlicense.org
Post 18 Aug 2021, 14:38
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7925
Location: Kraków, Poland
Tomasz Grysztar
bitRAKE wrote:
Even in non-numerical situations a numerical flag could be set and used with DEFINITE.
But DEFINITE does not prevent forward-reference then, because forward-referencing symbolic definition is unrolled before DEFINITE is evaluated.
Post 18 Aug 2021, 14:53
View user's profile Send private message Visit poster's website 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-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.