Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local Macronames in Modules #83

Open
kolnogorov opened this issue Sep 28, 2019 · 4 comments
Open

Local Macronames in Modules #83

kolnogorov opened this issue Sep 28, 2019 · 4 comments
Milestone

Comments

@kolnogorov
Copy link

Right now, if we have a MACRO in one module and then the MACRO with the same name in another module, they conflict with each other with error "Duplicate macroname", which is quite a reasonable. But woudn't it be more reasonablee to make macronames local in modules?

Here's an actual example from my current project to explain why it's needed.

Let's say we have two LZSA depackers in our project (LZSA1 and LZSA2), they both are wrapped in modules. But the latest versions of these depackers have macroses with the same names, thus we get an error.

So, it would be very good, if macronames wouldn't be global like now, but also a local in modules, just like the labels.

Thanks!

@kolnogorov kolnogorov changed the title Macros in Modules Local Macronames in Modules Sep 28, 2019
@ped7g
Copy link
Collaborator

ped7g commented Sep 28, 2019

I will think about... makes lot of sense to define better for v2.x, what macros/labels/modules are on the basic idea level and how they interact between.

I'm sort of afraid to touch this in v1.x, because such change would be yet another one breaking the compatibility with the 1.07-1.10 (before I joined this variant of sjasmplus), and just adding extra option always feels a bit dirty... but this seems like real issue with real project, so even dirty solution is better than none.

I will try to collect my thoughts and figure out pros/cons, and also check source how difficult it is to implement it, but I think this has good chance to show as extra --syntax option for v1.x, and unless I find some huge con on it, would be very likely default in v2.x

Thanks for the feedback, always appreciated. :)

@ped7g
Copy link
Collaborator

ped7g commented Sep 28, 2019

The implementation is not trivial, because macros while emitted are searched for by literal string (one search, found or not = emit or try the "name" as instruction), while labels in expressions are extended/collapsed with modules/etc prefixes and searched multiple times until some variant is found or all possible variants are exhausted.

I need more time to think about this, how to implement it. The first naive idea I had would probably cause quite some performance hit (both memory and speed), but anything else will take probably more than 5 lines change. :) ...so back to drawing board.

@ped7g
Copy link
Collaborator

ped7g commented Sep 28, 2019

There is some work-around which can maybe cover your current needs? (and is available right now in current sjasmplus)

You can use the DEFINE substitution to avoid the name collision, create some wrapper "asm" file for both each module DEFINE+UNDEFINE the macro name to make it unique in each case, and include the original source between those two.

Something like this:


    DEFINE clash mod1.clash

    MODULE mod1
        MACRO clash
            nop
        ENDM
        ; use clash within module (gets substituted too, so it works)
        clash
    ENDMODULE

    UNDEFINE clash

    DEFINE clash mod2.clash

    MODULE mod2
        MACRO clash
            cpl
        ENDM
        ; use clash within module
        clash
    ENDMODULE

    UNDEFINE clash

    ; use clash-es outside of modules
    mod1.clash
    mod2.clash

@kolnogorov
Copy link
Author

Thank you very much for so detailed answers!
Especially for the last solution with DEFINE. It's just some kind of a DEFINE textbook itself!

@ped7g ped7g added this to the v2.x milestone Sep 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants