2019-09-01 04:54:20 +00:00
|
|
|
;Edited to have duplicate labels (PROJ_ZERO, DPCODE).
|
2019-10-10 20:49:21 +00:00
|
|
|
CONST_ZERO equ $f0 ;project const
|
2019-10-23 05:43:10 +00:00
|
|
|
|
2019-09-01 03:32:43 +00:00
|
|
|
PROJ_ZERO equ $00 ;project addr
|
|
|
|
PROJ_ONE equ $01 ;project addr
|
|
|
|
|
|
|
|
org $1000
|
|
|
|
ldy PROJ_ZERO
|
|
|
|
lda (PROJ_ONE),y
|
2019-09-15 21:19:45 +00:00
|
|
|
sta $03 ;could be PROJ_ONE+2, but "nearby" is off
|
2019-09-01 03:32:43 +00:00
|
|
|
ldx $04
|
|
|
|
lda CONST_ZERO,S
|
|
|
|
sta $f1,S
|
|
|
|
]VAR_ZERO equ $00
|
|
|
|
]VAR_TWO equ $02
|
|
|
|
]VAR_THREE equ $03
|
|
|
|
]CONST_ZERO_VAR equ $f0
|
|
|
|
ldy ]VAR_ZERO
|
|
|
|
lda (]VAR_ZERO+1),y
|
|
|
|
sta ]VAR_THREE
|
|
|
|
ldx $04
|
|
|
|
lda ]CONST_ZERO_VAR,S
|
|
|
|
sta $f1,S
|
|
|
|
eor 0
|
|
|
|
ora 240,S
|
Label rework, part 6
Correct handling of local variables. We now correctly uniquify them
with regard to non-unique labels. Because local vars can effectively
have global scope we mostly want to treat them as global, but they're
uniquified relative to other globals very late in the process, so we
can't just throw them in the symbol table and be done. Fortunately
local variables exist in a separate namespace, so we just need to
uniquify the variables relative to the post-localization symbol table.
In other words, we take the symbol table, apply the label map, and
rename any variable that clashes.
This also fixes an older problem where we weren't masking the
leading '_' on variable labels when generating 64tass output.
The code list now makes non-unique labels obvious, but you can't tell
the difference between unique global and unique local. What's more,
the default type value in Edit Label is now adjusted to Global for
unique locals that were auto-generated. To make it a bit easier to
figure out what's what, the Info panel now has a "label type" line
that reports the type.
The 2023-non-unique-labels test had some additional tests added to
exercise conflicts with local variables. The 2019-local-variables
test output changed slightly because the de-duplicated variable
naming convention was simplified.
2019-11-18 21:26:03 +00:00
|
|
|
]PROJ_ZERO_1 equ $10 ;clash with project symbol
|
|
|
|
]DPCODE_1 equ $80 ;clash with user label
|
2019-09-01 03:32:43 +00:00
|
|
|
lda ]VAR_ZERO
|
|
|
|
lda ]VAR_ZERO+1
|
|
|
|
lda ]VAR_TWO
|
|
|
|
lda ]VAR_THREE
|
|
|
|
lda $04
|
Label rework, part 6
Correct handling of local variables. We now correctly uniquify them
with regard to non-unique labels. Because local vars can effectively
have global scope we mostly want to treat them as global, but they're
uniquified relative to other globals very late in the process, so we
can't just throw them in the symbol table and be done. Fortunately
local variables exist in a separate namespace, so we just need to
uniquify the variables relative to the post-localization symbol table.
In other words, we take the symbol table, apply the label map, and
rename any variable that clashes.
This also fixes an older problem where we weren't masking the
leading '_' on variable labels when generating 64tass output.
The code list now makes non-unique labels obvious, but you can't tell
the difference between unique global and unique local. What's more,
the default type value in Edit Label is now adjusted to Global for
unique locals that were auto-generated. To make it a bit easier to
figure out what's what, the Info panel now has a "label type" line
that reports the type.
The 2023-non-unique-labels test had some additional tests added to
exercise conflicts with local variables. The 2019-local-variables
test output changed slightly because the de-duplicated variable
naming convention was simplified.
2019-11-18 21:26:03 +00:00
|
|
|
lda ]PROJ_ZERO_1
|
2019-09-01 03:32:43 +00:00
|
|
|
lda $11
|
|
|
|
lda DPCODE
|
|
|
|
ldx PROJ_ZERO
|
|
|
|
ldx PROJ_ONE
|
|
|
|
ldx $02
|
|
|
|
bit $ffa9
|
|
|
|
ldy PROJ_ZERO
|
|
|
|
ldy PROJ_ONE
|
|
|
|
ldy $02
|
|
|
|
dfb $2c
|
|
|
|
]NH0 equ $00 ;not hidden
|
|
|
|
]NH1 equ $01 ;not hidden
|
|
|
|
L103C lda #$fe
|
|
|
|
beq L103C
|
|
|
|
ldy ]NH0
|
|
|
|
ldy ]NH1
|
|
|
|
ldy $02
|
|
|
|
nop
|
|
|
|
]PTR0 equ $10
|
|
|
|
]CONST0 equ $10
|
|
|
|
lda ]PTR0
|
|
|
|
ldx ]PTR0+1
|
|
|
|
ldy $12
|
|
|
|
lda (]CONST0,S),y
|
|
|
|
sta (]CONST0+3,S),y
|
|
|
|
;Test name redefinition. This is mostly of interest for assemblers without
|
|
|
|
;redefinable variables, but also of interest to the cross-reference window.
|
|
|
|
]PTR equ $20 ;#1
|
|
|
|
ldx ]PTR
|
|
|
|
]PTR equ $22 ;#2
|
|
|
|
ldx ]PTR
|
|
|
|
]PTR equ $24 ;#3
|
|
|
|
ldx ]PTR
|
2019-09-20 21:05:17 +00:00
|
|
|
:PTR_1 nop
|
2019-09-01 03:32:43 +00:00
|
|
|
]PTR_A equ $20
|
|
|
|
ldy ]PTR_A
|
|
|
|
]PTR_B equ $1f
|
|
|
|
ldy ]PTR_B+1
|
|
|
|
]PTR_C equ $1d
|
|
|
|
ldy ]PTR_C+3
|
|
|
|
]PTR_D equ $21
|
|
|
|
ldy ]PTR_C+3
|
|
|
|
]VAL0 equ $30
|
|
|
|
]VAL1 equ $31
|
|
|
|
]VAL2 equ $32
|
|
|
|
]VAL3 equ $33
|
|
|
|
]VAL4 equ $34
|
|
|
|
]VAL5 equ $35
|
|
|
|
and ]VAL0
|
|
|
|
and ]VAL1
|
|
|
|
and ]VAL2
|
|
|
|
and ]VAL3
|
|
|
|
and ]VAL4
|
|
|
|
and ]VAL5
|
|
|
|
]VAL14 equ $31
|
|
|
|
and ]VAL0
|
|
|
|
and ]VAL14
|
|
|
|
and ]VAL14+1
|
|
|
|
and ]VAL14+2
|
|
|
|
and ]VAL14+3
|
|
|
|
and ]VAL5
|
|
|
|
]DPNOP equ $80 ;same as org
|
|
|
|
lda DPCODE
|
|
|
|
jsr DPCODE
|
|
|
|
rts
|
|
|
|
|
|
|
|
org $0080
|
|
|
|
DPCODE nop
|
|
|
|
lda DPCODE
|
|
|
|
lda: DPCODE
|
|
|
|
ldal DPCODE
|
2019-09-20 21:05:17 +00:00
|
|
|
:SPLIT1 lda #$2c
|
|
|
|
]SPLITTER equ $80
|
|
|
|
ldx $1234
|
|
|
|
beq :SPLIT1
|
|
|
|
:SPLIT2 lda $2c
|
|
|
|
ldx $5678
|
|
|
|
beq :SPLIT2
|
2019-09-01 03:32:43 +00:00
|
|
|
rts
|
|
|
|
|