2019-09-01 04:54:20 +00:00
|
|
|
;Edited to have duplicate labels (PROJ_ZERO, DPCODE).
|
2019-09-01 03:32:43 +00:00
|
|
|
.setcpu "65816"
|
2019-10-10 20:49:21 +00:00
|
|
|
CONST_ZERO = $f0 ;project const
|
2019-10-23 05:43:10 +00:00
|
|
|
|
2019-09-01 03:32:43 +00:00
|
|
|
PROJ_ZERO = $00 ;project addr
|
|
|
|
PROJ_ONE = $01 ;project addr
|
|
|
|
|
|
|
|
; .segment "SEG000"
|
|
|
|
.org $1000
|
|
|
|
.a8
|
|
|
|
.i8
|
|
|
|
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
|
2019-09-02 01:14:39 +00:00
|
|
|
VAR_ZERO .set $00
|
|
|
|
VAR_TWO .set $02
|
|
|
|
VAR_THREE .set $03
|
|
|
|
CONST_ZERO_VAR .set $f0
|
2019-09-01 03:32:43 +00:00
|
|
|
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
|
Fix various local variable de-duplication bugs
In 1.5.0-dev1, as part of changes to the way label localization
works, the local variable de-duplicator started checking against a
filtered copy of the symbol table. Unfortunately it never
re-generated the table, so a long-lived LocalVariableLookup (like
the one used by LineListGen) would set up the dup map wrong and
be inconsistent with other parts of the program.
We now regenerate the table on every Reset().
The de-duplication stuff also had problems when opcodes and
operands were double-clicked on. When the opcode is clicked, the
selection should jump to the appropriate variable declaration, but
it wasn't being found because the label generated in the list was
in its original form. Fixed.
When an instruction operand is double-clicked, the instruction operand
editor opens with an "edit variable" shortcut. This was showing
the de-duplicated name, which isn't necessarily a bad thing, but it
was passing that value on to the DefSymbol editor, which thought it
was being asked to create a new entry. Fixed. (Entering the editor
through the LvTable editor works correctly, with nary a de-duplicated
name in sight. You'll be forced to rename it because it'll fail the
uniqueness test.)
References to de-duplicated local variables were getting lost when
the symbol's label was replaced (due largely to a convenient but
flawed shortcut: xrefs are attached to DefSymbol objects). Fixed by
linking the XrefSets.
Given the many issues and their relative subtlety, I decided to make
the modified names more obvious, and went back to the "_DUPn" naming
strategy. (I'm also considering just making it an error and
discarding conflicting entries during analysis... this is much more
complicated than I expected it to be.)
Quick tests can be performed in 2019-local-variables:
- go to +000026, double-click on the opcode, confirm sel change
- go to +000026, double-click on the operand, confirm orig name
shown in shortcut and that shortcut opens editor with orig name
- go to +00001a, down a line, click on PROJ_ZERO_DUP1 and confirm
that it has a single reference (from +000026)
- double-click on var table and confirm editing entry
2020-01-14 01:54:47 +00:00
|
|
|
PROJ_ZERO_DUP1 .set $10 ;clash with project symbol
|
|
|
|
DPCODE_DUP1 .set $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
|
Fix various local variable de-duplication bugs
In 1.5.0-dev1, as part of changes to the way label localization
works, the local variable de-duplicator started checking against a
filtered copy of the symbol table. Unfortunately it never
re-generated the table, so a long-lived LocalVariableLookup (like
the one used by LineListGen) would set up the dup map wrong and
be inconsistent with other parts of the program.
We now regenerate the table on every Reset().
The de-duplication stuff also had problems when opcodes and
operands were double-clicked on. When the opcode is clicked, the
selection should jump to the appropriate variable declaration, but
it wasn't being found because the label generated in the list was
in its original form. Fixed.
When an instruction operand is double-clicked, the instruction operand
editor opens with an "edit variable" shortcut. This was showing
the de-duplicated name, which isn't necessarily a bad thing, but it
was passing that value on to the DefSymbol editor, which thought it
was being asked to create a new entry. Fixed. (Entering the editor
through the LvTable editor works correctly, with nary a de-duplicated
name in sight. You'll be forced to rename it because it'll fail the
uniqueness test.)
References to de-duplicated local variables were getting lost when
the symbol's label was replaced (due largely to a convenient but
flawed shortcut: xrefs are attached to DefSymbol objects). Fixed by
linking the XrefSets.
Given the many issues and their relative subtlety, I decided to make
the modified names more obvious, and went back to the "_DUPn" naming
strategy. (I'm also considering just making it an error and
discarding conflicting entries during analysis... this is much more
complicated than I expected it to be.)
Quick tests can be performed in 2019-local-variables:
- go to +000026, double-click on the opcode, confirm sel change
- go to +000026, double-click on the operand, confirm orig name
shown in shortcut and that shortcut opens editor with orig name
- go to +00001a, down a line, click on PROJ_ZERO_DUP1 and confirm
that it has a single reference (from +000026)
- double-click on var table and confirm editing entry
2020-01-14 01:54:47 +00:00
|
|
|
lda PROJ_ZERO_DUP1
|
2019-09-01 03:32:43 +00:00
|
|
|
lda $11
|
|
|
|
lda z:DPCODE
|
|
|
|
ldx PROJ_ZERO
|
|
|
|
ldx PROJ_ONE
|
|
|
|
ldx $02
|
|
|
|
bit $ffa9
|
|
|
|
ldy PROJ_ZERO
|
|
|
|
ldy PROJ_ONE
|
|
|
|
ldy $02
|
|
|
|
.byte $2c
|
2019-09-02 01:14:39 +00:00
|
|
|
NH0 .set $00 ;not hidden
|
|
|
|
NH1 .set $01 ;not hidden
|
2019-09-01 03:32:43 +00:00
|
|
|
L103C: lda #$fe
|
|
|
|
beq L103C
|
|
|
|
ldy NH0
|
|
|
|
ldy NH1
|
|
|
|
ldy $02
|
|
|
|
nop
|
2019-09-02 01:14:39 +00:00
|
|
|
PTR0 .set $10
|
|
|
|
CONST0 .set $10
|
2019-09-01 03:32:43 +00:00
|
|
|
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.
|
2019-09-02 01:14:39 +00:00
|
|
|
PTR .set $20 ;#1
|
|
|
|
ldx PTR
|
|
|
|
PTR .set $22 ;#2
|
|
|
|
ldx PTR
|
|
|
|
PTR .set $24 ;#3
|
2019-09-01 03:32:43 +00:00
|
|
|
ldx PTR
|
|
|
|
PTR_1: nop
|
2019-09-02 01:14:39 +00:00
|
|
|
PTR_A .set $20
|
2019-09-01 03:32:43 +00:00
|
|
|
ldy PTR_A
|
2019-09-02 01:14:39 +00:00
|
|
|
PTR_B .set $1f
|
2019-09-01 03:32:43 +00:00
|
|
|
ldy PTR_B+1
|
2019-09-02 01:14:39 +00:00
|
|
|
PTR_C .set $1d
|
2019-09-01 03:32:43 +00:00
|
|
|
ldy PTR_C+3
|
2019-09-02 01:14:39 +00:00
|
|
|
PTR_D .set $21
|
2019-09-01 03:32:43 +00:00
|
|
|
ldy PTR_C+3
|
2019-09-02 01:14:39 +00:00
|
|
|
VAL0 .set $30
|
|
|
|
VAL1 .set $31
|
|
|
|
VAL2 .set $32
|
|
|
|
VAL3 .set $33
|
|
|
|
VAL4 .set $34
|
|
|
|
VAL5 .set $35
|
2019-09-01 03:32:43 +00:00
|
|
|
and VAL0
|
|
|
|
and VAL1
|
|
|
|
and VAL2
|
|
|
|
and VAL3
|
|
|
|
and VAL4
|
|
|
|
and VAL5
|
2019-09-02 01:14:39 +00:00
|
|
|
VAL14 .set $31
|
2019-09-01 03:32:43 +00:00
|
|
|
and VAL0
|
|
|
|
and VAL14
|
|
|
|
and VAL14+1
|
|
|
|
and VAL14+2
|
|
|
|
and VAL14+3
|
|
|
|
and VAL5
|
2019-09-02 01:14:39 +00:00
|
|
|
DPNOP .set $80 ;same as org
|
2019-09-01 03:32:43 +00:00
|
|
|
lda z:DPCODE
|
|
|
|
jsr DPCODE
|
|
|
|
rts
|
|
|
|
|
|
|
|
; .segment "SEG001"
|
|
|
|
.org $0080
|
|
|
|
DPCODE: nop
|
|
|
|
lda DPCODE
|
|
|
|
lda a:DPCODE
|
|
|
|
lda f:DPCODE
|
2019-09-20 21:05:17 +00:00
|
|
|
SPLIT1: lda #','
|
|
|
|
SPLITTER .set $80
|
|
|
|
ldx $1234
|
|
|
|
beq SPLIT1
|
|
|
|
@SPLIT2: lda ','
|
|
|
|
ldx $5678
|
|
|
|
beq @SPLIT2
|
2019-09-01 03:32:43 +00:00
|
|
|
rts
|
|
|
|
|