the temporary number-labels may not work inside IFUSED, if the first pass doesn't already detect the label as used...
I did rewrite temporary label implementation in v1.11.1 I think? As it was not working correctly when amount of lines did change between passes, but thinking about it (not 100% sure), maybe now they don't mind changing amount of lines, but require to form the same list across all passes, so if some of them are missing because of IFUSED in first pass was false, then true later, the total list is different, and it maybe fails because of that.
If you have only few of them, consider to change them to local labels? Or include the libraries after the main code, when the IFUSED will already know in first pass, which routines are used?
Of course it would be better to fix sjasmplus, but that may take some time, or somebody else doing it, right now I'm waiting for z00m to release 1.18.3, not planning to work on sjasmplus this +-year.
Still, if you can produce some minimal failing example, it may help to target the bug easier.
About calling from one module to other ... the `call @other_module.function` is IMO best way, as that's what the source is really doing. Without "@" the label `my_module.other_module.function` is first-priority and other variants are searched only if that fails. Which usually still works for almost anything, except IFUSED. But I don't consider this 100% bug on sjasmplus side, it's heuristic, if you don't specify full global name, and as any heuristic - it's not perfect. (and there's no 100% correct fix for it, whatever you do, you can create anti-example where the new method will fail, as the whole concept is ambiguous).
... or you can try to zip your project and send it to me to see if I can quickly patch it to assemble with latest version (would be probably quicker to patch your sources, than sjasmplus......and maybe not).
- - - Updated - - -
ah, you (krt17 - thank you) did produce the minimal example. And seems I remember it correctly, the heuristic guessing what label you want to call at `call m2.used2` fails as the `n1.m2.used2` is first-priority in first pass, then the `used2: ifused` in first pass is "false", which makes the "2" temporary label non-existent in first pass.
You can fix such source either by being more explicit in the call using "@" to target the correct module `call @m2.used2`, or you can change the "2" temporary label to some local label. Using those number-labels inside IFUSED blocks is really bad idea since v1.11.1 ... and using them before is really bad idea too... Hmm... I guess it's just bad idea in any case. Use regular labels.
edit2: but I guess the temporary labels stuff is more like bug... maybe it could accept changes to the temporary labels list between first and second pass, but I'm not sure if that is enough to resolve this. I will keep that example around and maybe check it later, what can be done about it. 0xDEAD: anyway, thank you for reporting your issue, and sorry I don't have some perfect fix for you.




...and maybe not).
Ответить с цитированием