[fasmg] conditional assembly

Index > Compiler Internals > [fasmg] conditional assembly

Author

Thread

sylware

Joined: 23 Oct 2020
Posts: 456
Location: Marseille/France

sylware 16 Aug 2021, 12:45

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?

16 Aug 2021, 12:45

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20430
Location: In your JS exploiting you and your system

revolution 16 Aug 2021, 12:57

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.

16 Aug 2021, 12:57

sylware

Joined: 23 Oct 2020
Posts: 456
Location: Marseille/France

sylware 16 Aug 2021, 13:36

Ok, I have to keep in mind this multi-pass oscillating thingy then.

I guess I need to write "pass idempotent" configuration instructions.

16 Aug 2021, 13:36

bitRAKE

Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri

bitRAKE 16 Aug 2021, 14:05

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)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

16 Aug 2021, 14:05

bitRAKE

Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri

bitRAKE 16 Aug 2021, 14:25

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

(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.)

16 Aug 2021, 14:25

Tomasz Grysztar

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

Tomasz Grysztar 16 Aug 2021, 16:49

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".

16 Aug 2021, 16:49

Tomasz Grysztar

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

Tomasz Grysztar 16 Aug 2021, 16:49

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.

16 Aug 2021, 16:49

sylware

Joined: 23 Oct 2020
Posts: 456
Location: Marseille/France

sylware 18 Aug 2021, 13:58

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?

18 Aug 2021, 13:58

bitRAKE

Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri

bitRAKE 18 Aug 2021, 14:38

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)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

18 Aug 2021, 14:38

Tomasz Grysztar

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

Tomasz Grysztar 18 Aug 2021, 14:53

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.

18 Aug 2021, 14: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