1
0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-05 19:50:33 +00:00
6502bench/SourceGen/SGTestData/Expected/2019-local-variables_acme.S

228 lines
5.7 KiB
ArmAsm
Raw Normal View History

;Edited to have duplicate labels (PROJ_ZERO, DPCODE).
!cpu 65816
CONST_ZERO = $f0 ;project const
PROJ_ZERO = $00 ;project addr
PROJ_ONE = $01 ;project addr
* = $1000
!as
!rs
ldy PROJ_ZERO
lda (PROJ_ONE),y
sta $03 ;could be PROJ_ONE+2, but "nearby" is off
ldx $04
lda CONST_ZERO,S
sta $f1,S
!zone Z00000c
.VAR_ZERO = $00
.VAR_TWO = $02
.VAR_THREE = $03
.CONST_ZERO_VAR = $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
!zone Z00001c
.VAR_ZERO = $00
.VAR_TWO = $02
.VAR_THREE = $03
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 = $10 ;clash with project symbol
.DPCODE_DUP1 = $80 ;clash with user label
.CONST_ZERO_VAR = $f0
lda .VAR_ZERO
lda .VAR_ZERO+1
lda .VAR_TWO
!zone Z000022
.VAR_ZERO = $00
.VAR_TWO = $02
.VAR_THREE = $03
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 = $10 ;clash with project symbol
.DPCODE_DUP1 = $80 ;clash with user label
.CONST_ZERO_VAR = $f0
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
lda $11
lda+1 DPCODE
!zone Z00002c
ldx PROJ_ZERO
ldx PROJ_ONE
ldx $02
bit $ffa9
ldy PROJ_ZERO
ldy PROJ_ONE
ldy $02
!byte $2c
!zone Z00003c
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
L103C lda #$fe
beq L103C
ldy .NH0
ldy .NH1
ldy $02
nop
!zone Z000047
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $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.
!zone Z000051
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR = $20 ;#1
ldx .PTR
!zone Z000053
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR = $22 ;#2
ldx .PTR
!zone Z000055
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR = $24 ;#3
ldx .PTR
@PTR_1 nop
!zone Z000058
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR_A = $20
.PTR = $24 ;#3
ldy .PTR_A
!zone Z00005a
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR_B = $1f
.PTR = $24 ;#3
ldy .PTR_B+1
!zone Z00005c
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR_C = $1d
.PTR = $24 ;#3
ldy .PTR_C+3
!zone Z00005e
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR_C = $1d
.PTR_D = $21
.PTR = $24 ;#3
ldy .PTR_C+3
!zone Z000060
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR_C = $1d
.PTR_D = $21
.PTR = $24 ;#3
.VAL0 = $30
.VAL1 = $31
.VAL2 = $32
.VAL3 = $33
.VAL4 = $34
.VAL5 = $35
and .VAL0
and .VAL1
and .VAL2
and .VAL3
and .VAL4
and .VAL5
!zone Z00006c
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR_C = $1d
.PTR_D = $21
.PTR = $24 ;#3
.VAL0 = $30
.VAL14 = $31
.VAL5 = $35
and .VAL0
and .VAL14
and .VAL14+1
and .VAL14+2
and .VAL14+3
and .VAL5
!zone Z000078
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR_C = $1d
.PTR_D = $21
.PTR = $24 ;#3
.VAL0 = $30
.VAL14 = $31
.VAL5 = $35
.DPNOP = $80 ;same as org
lda+1 DPCODE
jsr DPCODE
rts
!pseudopc $0080 {
DPCODE nop
lda+1 DPCODE
lda+2 DPCODE
lda+3 DPCODE
@SPLIT1 lda #','
!zone Z00008a
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR_C = $1d
.PTR_D = $21
.PTR = $24 ;#3
.VAL0 = $30
.VAL14 = $31
.VAL5 = $35
.SPLITTER = $80
ldx $1234
beq @SPLIT1
@SPLIT2 lda ','
!zone Z000091
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
.PTR_C = $1d
.PTR_D = $21
.PTR = $24 ;#3
.VAL0 = $30
.VAL14 = $31
.VAL5 = $35
.SPLITTER = $80
ldx $5678
beq @SPLIT2
rts
} ;!pseudopc