You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm just thinking out loud here and would appreciate any input.
pyz80 has global symbols and local symbols (@-prefix).
global: equ 1 @local: equ 2
Global symbols can be exported (--exportfile) and imported (--importfile) allowing linker-type sharing between programs.
When used for linking, a further distinction may be useful to only export external entry points / labels.
For using a multi-purpose include file, the global symbol is unusable since it can only be set once and the local symbol has no effect:
; progA.s
section: equ "A"
include "section.i"
; prog B.s
section: equ "B"
include "section.i"
; section.i
if section == "A" then
...
else
...
endif
In the above example both progs can be assembled, but if the symbols of A are exported and imported when assembling B, assembly will fail since the section symbol is being redefined with a different value than the existing definition.
Additionally (or alternatively) an undefine symbol could help, this would allow including section.i multiple times within the same source with different parameters.
Alternatively (again) local symbols could be passed in with the include, something like:
include "section.i" @section="A"
Which would define local section for the scope of that section.i only.
The text was updated successfully, but these errors were encountered:
I think my only worry with any solution is whether the changing value would cause any side-effects in the multi-pass assembly. It might only be a problem if the same symbols were used in generated code. I suspect if ithey're only used for if blocks then it will be fine.
The use case you describe feel a lot like how pre-processor macros are used in C, with undefine being an equivalent to #undef. Adding an undefine directive would probably be relatively simple, if you wanted to see how it worked.
Anything needing temporary symbols might require some symbol table refactoring to handle the layering. Though those changes might also simplify the current implementation of local symbols that use a location suffix internally.
I'm just thinking out loud here and would appreciate any input.
pyz80 has global symbols and local symbols (@-prefix).
global: equ 1
@local: equ 2
Global symbols can be exported (
--exportfile
) and imported (--importfile
) allowing linker-type sharing between programs.When used for linking, a further distinction may be useful to only export external entry points / labels.
For using a multi-purpose include file, the global symbol is unusable since it can only be set once and the local symbol has no effect:
In the above example both progs can be assembled, but if the symbols of A are exported and imported when assembling B, assembly will fail since the
section
symbol is being redefined with a different value than the existing definition.Additionally (or alternatively) an
undefine
symbol could help, this would allow including section.i multiple times within the same source with different parameters.Alternatively (again) local symbols could be passed in with the include, something like:
Which would define local section for the scope of that section.i only.
The text was updated successfully, but these errors were encountered: