include resolution process in famsg

Index > Main > include resolution process in famsg

Author

Thread

fabbel

Joined: 30 Oct 2012
Posts: 109

fabbel 06 Oct 2025, 12:04

Hi Tomasz,
Am working on extending include features via macro / calm
* typ., my own version of "include once"
* but also "deferred exec" of block of instructions at the end of current include file ( as opposed to at end of script as done via postpone)

in the process, the below questions/topics arised:
1/
... unless mistaken, I see no explicit details of the include resolution process in fasmg doc...
as I read in fasmg source, I understand it normally is: try source file directory first, then %include% env variable (if it exists).
Can u pls confirm / elaborate ? ... maybe worth putting in the manual ?

2/
while playing with postpone for inspiration / see how to collaborate with it, I came to experience behavior of postpone that I was not expecting (but came to like / cope with) :
I initially thought pospone block would only care for "regular" macro inx / fasmg directives inside postpone ... end postpone block - seeing it as a king of "specialized macro"...
... then below sample puzzled me for some time..

Code:

include 'utility/xcalm.inc'

calminstruction postpone
                display '*** postpone override' bappend 0x0A0D

                asm postpone

                display '*** executing postpone' bappend 0x0A0D
end calminstruction

postpone
        display '...  some postponed block of inx here', 13, 10
end postpone

display '... script body here ...', 13, 10

=> this yields below ouput:

Quote:

flat assembler version g.ktge
*** postpone override
*** executing postpone
... script body here ...
*** executing postpone
... some postponed block of inx here

... which is to say, when executing postpone block at the end of script, it appears to be calling back into postpone calm override, in the middle of calm inx, just after the line
asm postpone
... while i would initially have expected the '*** executing postpone' msg to display only once, at the time the postpone block is set up (just like '*** postpone override' msg).
Again, i finally manage and appreciate this behavior, but i wonder if it wouldn't deserve bit more explicit description

06 Oct 2025, 12:04

fabbel

Joined: 30 Oct 2012
Posts: 109

fabbel 06 Oct 2025, 12:18

.. another was to put it: **any** code that is 'installed' after pospone directive will get executed at end of script, be it regular fasmg (macro) code / directives, or even alm code (even if part of enclosing calm inx)

06 Oct 2025, 12:18

Tomasz Grysztar

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

Tomasz Grysztar 06 Oct 2025, 14:28

fabbel wrote:

1/
... unless mistaken, I see no explicit details of the include resolution process in fasmg doc...
as I read in fasmg source, I understand it normally is: try source file directory first, then %include% env variable (if it exists).
Can u pls confirm / elaborate ? ... maybe worth putting in the manual ?

I thought this should be compatible with fasm 1, which has it documented as follows:

flat assembler manual wrote:

The file is first searched for in the directory containing file which included it and when it is not found there, the search is continued in the directories specified in the environment variable called INCLUDE (the multiple paths separated with semicolons can be defined there, they will be searched in the same order as specified). If file was not found in any of these places, preprocessor looks for it in the directory containing the main source file (the one specified in command line).

But it seems I forgot to ensure that fasmg is compatible, and unlike fasm 1 it also checks current directory before paths from the environment variable. While this is normally not very noticeable difference, I should at least document it properly, as you noted.

fabbel wrote:

while playing with postpone for inspiration / see how to collaborate with it, I came to experience behavior of postpone that I was not expecting (but came to like / cope with) :
I initially thought pospone block would only care for "regular" macro inx / fasmg directives inside postpone ... end postpone block - seeing it as a king of "specialized macro"...

POSTPONE has been implemented as a control directive (and is defined as such by the manual), so it controls the flow of the assembly in a similar way to other control directives like WHILE.

I recall I briefly experimented with POSTPONE being a single-use macro (similarly to how it was implemented in the preprocessor of fasm 1), but implementing it as a control directive felt simpler and more elegant.

06 Oct 2025, 14:28

fabbel

Joined: 30 Oct 2012
Posts: 109

fabbel 06 Oct 2025, 15:29

thx for feedback !
Regarding postpone, indeed, it is defined as a control directive in the manual... it is just that I initially didn't anticipate this kind of effect (even if now appreciate like it is )

... just wanted to share experience really
... i mean control directives are - for me - associated with "regular code"
(as opposed to alm code, mean typ. directive like 'repeat/end repeat', 'if/end if', ... cannot normally show up inside calm inx impl.,
while, conversly, alm can only appear between calminstruction... end calminstruction)
... so it just confused my understanding as I initially just didn't not expect postponed execution - even if directive - to be able to call/jump directly inside alm code w/o explicit switch to alm
... at some point while experimenting, I even thought that at end of script, postpone was starting again from initial postpone statement, thus re-executing the whole postpone override code again
... before I realized it is really the "intrinsic" postpone directive itself that is setting the point of exec at end of script - no matter what/where that is....

06 Oct 2025, 15:29

Tomasz Grysztar

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

Tomasz Grysztar 06 Oct 2025, 18:11

The state of fasmg's control flow can be stored and resumed at any point. This is essential for things like CALM code calling a macro, which in turn may call another CALM instruction and so on. A simple example with REPEAT (another control directive) demonstrates that everything can be rewound:

Code:

calminstruction demo
        asm repeat 3
        display '!'
end calminstruction

demo
end repeat

Unless the counter reached the limit, END REPEAT restores the source context saved by REPEAT (it's a SourceContext structure in fasmg's internals), which points the assembler back to the CALM code inside "demo".

What makes it especially tricky is the fact that CALM commands like DISPLAY do not obey the assembly state which for normal (textual) instructions determines whether to execute only the unconditional ones (like when REPEAT has 0 count, or IF has a false condition, or POSTPONE is executed during the normal assembly pass, which also puts it into this "skip block" mode). It makes these command essentially like unconditional instructions and this is what caused the message to show up twice in your example.

06 Oct 2025, 18:11

< 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