search

simonowen / pyz80

pyz80 - a Z80 cross assembler
GNU General Public License v2.0
17 stars 8 forks source link

Symbols / Linking #18

Open stefandrissen opened 3 years ago

stefandrissen commented 3 years ago

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.

simonowen commented 3 years ago

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.