SjASMPlus от z00m

[krt17]

Я тоже не понимаю как можно было так сломать, но тем не менее

- - - Добавлено - - -

Так то бог с ним, сломал и сломал, просто надо выпилить из синтаксиса и убрать из доков.

[Ped7g]

Так то бог с ним, сломал и сломал, просто надо выпилить из синтаксиса и убрать из доков.

Ah, interesting, but I think I know what is happening.

The line `call test1` is inside module `test`, so it has ambiguous interpretation, it can be either `call test.test1` calling another inside-module label, or it can be interpreted as `call test1` in global namespace without module.

If you remove the `IFUSED` test, the global `test1` will be defined, and in second+ pass the `call` will find it and use it, interpreting it as global label.

But with the `IFUSED` the global label is never defined, and the `call` will always trigger only the "in-module" interpretation (marking "test.test1" label as "used + not_defined", but that's not relevant to the `IFUSED` in include file, so that will be always false).

You can either use the other syntax of `IFUSED` after the label ("style1a"/"style1b" in my previous example, which do define the global label even when the label is unused, and the code is skipped, i.e.:

test1   IFUSED
            ret
        ENDIF

Or you can disambiguate the call line by using `call @test1` to make it clear the "test1" is label from global name space, not belonging to current `test` module.

(I guess you do not want the `test1` to belong into module `test`, otherwise also defining the `test1` routine inside the module will fix the error too, but then you have `test.test1` routine, not `test1`).

To fix this (in relaxed syntax way, allowing the source you posted as valid) the `call` would have to generate ambiguous two-variant "possibly used label" meta data, and the IFUSED would have to check all these variants then... Which is unfortunately not trivial fix. (and without thinking about it properly, I would be afraid of such change to backfire by having old source in modules generating suddenly lot more global undefined+used labels in the table, but maybe that's no issue at all, I don't know)

(and I'm not a big fan of relaxed syntax which has ambiguous interpretations, so I'm a bit tempted to fix this by removing "style2" syntax of IFUSED ... ... and also remove the global labels search when inside the module, to make the `@` mandatory in this case ... that would be like "correct" fix by my taste, but I guess that's not helping to actual users :P )

So at this moment I don't want to try to fix this, IMO either using the `@` or the "style1a" IFUSED syntax is good-enough workaround? But I should probably add this bug description to IFUSED docs as known bug.

Sorry for the inconvenience, I hope you can manage around this... (and of course thank you for the report)

[krt17]

Проблема лишь в том что в старом синтаксисе не работает, а в новом работает, почему в одном случае оно помечает использование в глобальных а во втором нет? У меня не так много включаемых библиотек, я просто их поправил. Глобальный поиск по собаке из модулей наверное правильно, пожалуй переделаю свои потихоньку, через пару лет.

[Ped7g]

Проблема лишь в том что в старом синтаксисе не работает, а в новом работает, почему в одном случае оно помечает использование в глобальных а во втором нет? У меня не так много включаемых библиотек, я просто их поправил. Глобальный поиск по собаке из модулей наверное правильно, пожалуй переделаю свои потихоньку, через пару лет.

The difference is subtle, the old syntax does this:
pass1:
`call` will search for both "@test.test1" and "@test1", both fails, adds into symbol table "@test.test1" as "used + undefined" symbol.
`ifused test1` will check table for `@test1`, find nothing, emit no code (and no label).
pass2 + pass3:
the same thing happens, in pass3 the `call` reports missing label "@test.test1".

New syntax:
pass1:
`call` will search for both "@test.test1" and "@test1", both fails, adds into symbol table "@test.test1" as "used + undefined" symbol.
`test1: ifused` will define "@test1" label ("unused + defined" type), will check for usage, no usage, skip block
pass2:
`call` will search for both... and find the "@test1" defined ("defined" type wins over "@test.test1" - which exist, but is "undefined" type), marking the "@test1" as "used"
`test1: ifused` will check usage flag, and emit the block, because now it is used
pass3:
same as pass2
(the "@test.test1" usage symbol is simply hanging there and being ignored, as the global "@test1" will work for all the code).

You can either change your libraries to "new" syntax, or you can do at least one usage in source with full label (`call @test1`), that will be enough to trigger the "old" syntax of IFUSED (if there will be other lines "call test1", they will still prefer @test.test1 in first pass, but since second pass those will find the global @test1 too, so they will end with correct value in pass 3).

So you can choose if you want to edit the old library or the new code.

Makes me wonder under which version your source did compile before, did it work with some older version of sjasmplus? Or did you add modules later and didn't notice until that IFUSED mystery?

[Ped7g]

https://github.com/z00m128/sjasmplus...es/tag/v1.14.3

v1.14.3 changelog:
- fix detection of `.end:` and `.END` labels when `--dirbol` is used
- added export of SLD (Source Level Debugging) data for NDS-NextDevSystem
- added `--longptr` option to allow labels outside of 16b address space
- docs: added small details about FPOS, SAVETAP, IFUSED
- fix assembling-time reported in linux

Documentation http://z00m128.github.io/sjasmplus/documentation.html (or in the package/cloned source).

The minor fixes and `--longptr` option are result of cooperation with "one abandoned project by Daemos" for MSX platform, who was trying to migrate from Tniasm to sjasmplus (now successfully migrated).

From the other feedback since v1.14.2... usually most of the issues turn out to be "lack of documentation" of sjasmplus specifics, when it doesn't meet expectations of user and it works in different way than they expect.

For example the (internal) distinction between modules+labels/macros/defines (all of them being different kind, and applied to the source line in different stage of assembling) is common source of confusion, as each feature is maybe too independent and having its own rules (how it works).

So I will try in future to add few more chapters to docs about how actually sjasmplus internally works and what are expected ways of usage.

If you have some issue on your own sources, if everything fails, don't hesitate to post some example here, or send me whole project so I can check the problem and suggest some workaround/fix. Obviously some of the reported issues would be nice to fix a bit more on the assembler side and less in the project source, but I don't want to change general behaviour of v1.14.x versions, adding only new features when they don't collide with old syntax and behaviour.

(the v1.14 series are sort of "final" versions of sjasmplus v1.x, and by the amount of new bugs found+fixed in recent releases I think I'm there already, with only minor fix releases coming in future... and then maybe later one day the v2.x will be released - which will have also behaviour and syntax changes, so I'm collecting also ideas for behaviour changes for the v2.x).

[zebest]

- fix detection of `.end:` and `.END` labels when `--dirbol` is used

Кстатида. про "END"
Это теперь зарезервированное слово?? Псевдокоманда?? или как и раньше - может быть простой меткой??
Столкнулся с непонятным поведением. Если стоИт точно в начале строки. как метка, то компилируется, и сзздается выходной файл, ну к примеру .tap
Если же не в начале строки - то так же компилируется, без ошибок, но файла не создает.
Так

end         
        savetap "primer.tap" ,start

и так

         end         
        savetap "primer.tap" ,start

в другом, хорошем, компиляторе - пофиг на расположение.

[Advertiser]

[Ped7g]

Кстатида. про "END"
Это теперь зарезервированное слово??

It was always directive, documented as: http://z00m128.github.io/sjasmplus/d...on.html#po_end

The assembler will stop at this point. The pseudo-op END does NOT work in the beginning of line (even with --dirbol).

(it's more than 10 years old paragraph)

But it didn't work as documented, so I fixed it around v1.11 or v1.12 to work as the docs describe.

*Today* I'm not sure if that was the smartest idea, maybe I should have kept the dirEND() as it was, and change the documentation to describe what the code really does (was just setting "start" address for some other commands like savetap/savesna/...).

в другом, хорошем, компиляторе - пофиг на расположение.

Nice, so you can use whatever you like and you have options.
But JFYI, if you are talking about https://github.com/sjasmplus/sjasmplus ... it has the same quote in the documentation. So if the END doesn't stop assembling in it, in my view it is a bug (I'm used to treat docs as source of truth, so for me it was clearly bug in the code, but as I wrote, with the experience I collected in recent months, I'm not that sure about it, changing the docs post-fact may be sometimes better solution, than "fixing bug" in the code).

The examples you posted work as intended.
(`END` at beginning of line is label, after whitespace it's keyword, the --dirbol does NOT enable END at beginning of line (fully fixed in 1.14.3) ... plus add the syntax ambiguity of sjasmplus, where every directive can be prefixed with single dot, so the same rules apply to ".END" string, beginning of line = local label, after white space = stopping assembler)

[Shadow Maker]

It was always directive, documented as: http://z00m128.github.io/sjasmplus/d...on.html#po_end

(it's more than 10 years old paragraph)

But it didn't work as documented, so I fixed it around v1.11 or v1.12 to work as the docs describe.

*Today* I'm not sure if that was the smartest idea, maybe I should have kept the dirEND() as it was, and change the documentation to describe what the code really does (was just setting "start" address for some other commands like savetap/savesna/...).

By me you should just change the docs instead of changing the behavior, as in 10 years people have lot of source code and probably there are quite a lot of similar things, which make people frustrate on such trivial matter.

[dlancer]

I would rather write


So I can easily change the variable name I pass instead of having to change all of them every time I want to change filename.

Вот так можно:

   define filename "test.tap"

   savetap filename, BASIC,"noAutorun",label,100  
   ....

[Shadow Maker]

Вот так можно:

   define filename "test.tap"

   savetap filename, BASIC,"noAutorun",label,100  
   ....

Ясно, я что-то не подумал. Ок.