calm issue in famsg ver. l8vn (symbol recognition context?)

Index > Main > calm issue in famsg ver. l8vn (symbol recognition context?)

Author

Thread

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 04 Nov 2026, 09:08

Hi Tomasz,

Seems I am finding an issue / regression with fasmg latest version l8vn...
Behavior of below snippet is different under new ver. l8vn, vs. ver. kta0 used as reference.

Can u pls have a look and revert.
Tx

Code:

calminstruction calminstruction?.initsym? var@*, val
                publish var@, val
end calminstruction

calminstruction pub var@*, val*
                publish var@, val
end calminstruction

VAR = 0

calminstruction test val*
        local _var@, _tmp

        initsym _var@, VAR

                display '*** test' bappend 0x0A0D

                arrange _tmp, VAR
                stringify _tmp
                display 0x09 bappend '-> before: VAR = ' bappend _tmp bappend 0x0A0D

                compute val, val
                arrange _tmp, val
                stringify _tmp
                display 0x09 bappend '-> ... using val = ' bappend _tmp bappend 0x0A0D

                call pub, _var@, val

                arrange _tmp, VAR
                stringify _tmp
                display 0x09 bappend '-> after: VAR = ' bappend _tmp bappend 0x0A0D

end calminstruction

test 36

rept 1, __var:VAR
        display '*** cross-check -> VAR = ', `__var, 13, 10
end rept

=> with ver. ver. kta0, this yields (as expected) :

Quote:

flat assembler version g.kta0
*** test
-> before: VAR = 0
-> ... using val = 36
-> after: VAR = 36
*** cross-check -> VAR = 36

1 pass, 0 bytes.

=> while new ver. l8vn yields unexpected result as per below:

Quote:

flat assembler version g.l8vn
*** test
-> before: VAR = 36
-> ... using val = 36
-> after: VAR = 36
*** cross-check -> VAR = 0

2 passes, 0 bytes.

seems VAR is no longer recognized inside calm as existing per initial external defintion ... calm appear to be referencing a local undefined VAR, leading to fwd-ref and req. 2 passes.

04 Nov 2026, 09:08

Tomasz Grysztar

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

Tomasz Grysztar 04 Nov 2026, 11:28

The exact version when this changed was l4gs, and I mentioned the change as a side-note in an a thread about another issue.

I changed PUBLISH command to follow fasmg's regular definition rules, which causes it to create a new local symbol even if a global with the same name exists. This puts it line with commands like "=", "equ", etc.

For instance, this example from the manual was not fully correct before the fix:

Code:

        calminstruction (var) constequ? val
                transform val
                publish var:, val
        end calminstruction

Code:

a constequ 1

namespace a
        a constequ 2    ; this should not cause an error
end namespace

In your case, a link to "VAR" should therefore be made with global context, and not with a local one like "initsym" does.

04 Nov 2026, 11:28

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 04 Nov 2026, 12:31

Such changes should be documented at the very least.....
expecting everyone to be aware of some discussion and its impact burried deep in the forum does not seem right to me...
Now i have a bunch of code relying on previous behavior, and am forced to audit back / change all of this... really does not make sense esp if no one never complained about it to justify the correction...

04 Nov 2026, 12:31

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 04 Nov 2026, 12:34

... this had been in place for years and became a de-facto feature...
.. cannot silently change without calling for comment i would say

04 Nov 2026, 12:34

Tomasz Grysztar

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

Tomasz Grysztar 04 Nov 2026, 12:38

As it was, it was a bug, because it did not follow the documented rules. This is why there was no related update of documentation.

04 Nov 2026, 12:38

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 04 Nov 2026, 12:42

did anyone ever complained about it ?

04 Nov 2026, 12:42

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 04 Nov 2026, 12:45

how can u garantee that that this or any other side-effect of current code, even if considered abnormal are not used as a feature ?
same situation for any piece of software
then even if 'supposedly a bug from a purist perspective... this should be documented anyhow... especially if no one ever noticed...

04 Nov 2026, 12:45

Tomasz Grysztar

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

Tomasz Grysztar 04 Nov 2026, 12:45

fabbel wrote:

did anyone ever complained about it ?

Well, I did. My "constequ" example (from the manual) was not working correctly, that was something to complain about (to myself).

04 Nov 2026, 12:45

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 04 Nov 2026, 12:46

... the whole oint is famsg is (suposedly) a community...

04 Nov 2026, 12:46

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 04 Nov 2026, 12:48

... otherwise no point in releasing it to the public...

04 Nov 2026, 12:48

Tomasz Grysztar

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

Tomasz Grysztar 04 Nov 2026, 13:30

fabbel wrote:

... otherwise no point in releasing it to the public...

If only someone told me 26 years ago...

04 Nov 2026, 13:30

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 04 Nov 2026, 13:45

don't get mad ... just to clarify and avoid any misunderstaning...
i certainly value ur work... and precisely bec. of this, that i allow myself to comment
.. here, i jus feel there should be some kind of official release notes channel... to notify improvements / bug fixes / ...

04 Nov 2026, 13:45

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 04 Nov 2026, 13:52

... otherwise anything that used to work just apear to be broken by new version, if related changes go silent / un-noticed
... i my case i spend a lot of time uni-testing and when things work, i tkae it for granted that the code is compliant, even with "side effects" factored in...
... realizing that all this time was potentially wasted is really frustrating...

04 Nov 2026, 13:52

Tomasz Grysztar

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

Tomasz Grysztar 04 Nov 2026, 14:17

I feel that my fault here is that the issue went unnoticed long enough to become an assumption in some codebases.

I should add that this bug struck into fasmg's core principles. As perhaps no one but me remembers, after I presented my initial concept of fasm 2 on fasmcon 2009, five years passed with next to no progress. I did not share anything, but I made several failed attempts in 2010-2011. I wanted to have preprocessing incorporated into assembler, but otherwise as much compatibility with fasm as possible, for example EQU still somewhat familiar for fasm's users, even if not 100% the same. At the same time I wanted more extensibility, with ability to define case-insensitive symbols of all kinds, and nestable namespaces.
And with so many targets to hit, my early attempts were falling apart. Usually because the guidelines led to contradictions, or to a behaviour that would be way too surprising even for fasm's standards. I gave up around 2012, thinking that I had been too ambitious and that it was simply not possible to have it all.

Which is why in 2014, when another discussion about namespaces nudged me to make one more attempt, I was incredibly enthusiastic once I found a solution that seemed to not fall apart immediately. This led to the creation of fasmg, with newly invented fundamental guidelines. I feel like only thanks to them the engine manages to handle as much as it does, and therefore I treat them very seriously.

These most important principles were the rules of identifiers, symbol overriding and namespace separation, as described in the initial chapters of the manual. It is no coincidence that it starts with them, they were the true foundation of the engine. And among them is the basic rule that definition should assign the value to the "closest" applicable symbol: a case-sensitive one (unless explicitly told otherwise) and in current namespace (but what is "current" can be altered by a linked context). In other words: on the stack of possible locations that a symbol identifier could refer to, we always modify the topmost one (while accessing the symbol's value browses down the stack to find a defined one).

That said, CALM (designed in 2019) explored new directions and bent some of the rules, which is probably why I did not notice the problem earlier. But the external interface should have still played by the book, as "constequ" example demonstrates.

04 Nov 2026, 14:17

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 04 Nov 2026, 15:15

I do see the rationale behind it... and even better now with the above explanations / clarifications. Tx
... ultimately, I feel it's more about the way changes are made apparent to end user
... rather than ground reason to make the change - for this i trust u strive to keep coherence / consitency - as u've demonstrated
... simply, as u said, here, the asumption had enough time (+ testings on my side) to became 'entranched' in my mind as normal expected behavior ...
(the irony is, as I remember, when i started using calm, i had somehow realized initially that initsym was "giving context outside the one local to calminstruction"
... but after sometime I forgot about it as my focus switched... and I ended up considering this as actual standard feature, esp. as it allowed me to build up using it as it was
... plus i wasn't even 100% sure i had got everything right - even after reading the manual numerous times - esp that part about basic symbol rules and namespaces, which do take time to fully grasp really)

04 Nov 2026, 15:15

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 05 Nov 2026, 09:02

just quickly coming back to initial code submission,
instead of a link to "VAR" to 'inject' global context (which req to enclose the code in a match block),
actually simply changing initsym _var@, VAR. to initsym _var@, VAR. (with trailing dot)
make it work as expected
... looks like an easier / ligther solution ... any comment / subtleties ?

Code:

calminstruction test val*
        local _var@, _tmp

        initsym _var@, VAR.                                             ; with trailing dot '.'

                display '*** test' bappend 0x0A0D

                arrange _tmp, VAR
                stringify _tmp
                display 0x09 bappend '-> before: VAR = ' bappend _tmp bappend 0x0A0D


                compute val, val
                arrange _tmp, val
                stringify _tmp
                display 0x09 bappend '-> ... using val = ' bappend _tmp bappend 0x0A0D


                call pub, _var@, val


                arrange _tmp, VAR
                stringify _tmp
                display 0x09 bappend '-> after: VAR = ' bappend _tmp bappend 0x0A0D

end calminstruction

Quote:

flat assembler version g.l8vn
*** test
-> before: VAR = 0
-> ... using val = 36
-> after: VAR = 36
*** cross-check -> VAR = 36

1 pass, 0 bytes.

05 Nov 2026, 09:02

Tomasz Grysztar

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

Tomasz Grysztar 05 Nov 2026, 09:10

fabbel wrote:

actually simply changing initsym _var@, VAR. to initsym _var@, VAR. (with trailing dot)
make it work as expected
... looks like an easier / ligther solution ... any comment / subtleties ?

Yes, it seems like a good solution, as it utilizes the feature that is present for this exact purpose. My bad that I failed to mention it!

05 Nov 2026, 09:10

fabbel

Joined: 30 Oct 2012
Posts: 131

fabbel 05 Nov 2026, 09:23

Tx for f/b !

05 Nov 2026, 09:23

< 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