1
0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-05 03:49:53 +00:00
6502bench/SourceGen/SGTestData/Expected/20190-non-unique-labels_64tass.S

112 lines
2.0 KiB
ArmAsm
Raw Normal View History

.cpu "6502"
* = $1000
L1000 lda #$00
_L1000 lda #$01
ldx L1000
ldy _L1000
ldx #$02
loop1 dex
bne loop1
ldx #$03
_loop1 dex
bne _loop1
global1 nop
ldx #$04
_loop ldy #$05
_loop1 dey
bne _loop1
dex
bne _loop
jmp loop
global2 .byte $ea
loop nop
global3 nop
ldx #$06
ldy #$07
dex
beq _fwd1
dey
beq _fwd2
_fwd1 nop
_fwd2 nop
global4 nop
ldx #$08
loop2 dex
global5 nop
bne loop2
nop
global6 nop
_spin1 jsr _spin2
_spin2 jsr _spin1
nop
_spin11 lda _spin1+7
beq _spin11
lda #<_spin1
ldx #<_spin2
lda #>_spin1
ldx #>_spin2
bne _skip
.word _spin1
.word _spin2
.word _spin11
.byte <_spin1
.byte <_spin2
.byte >_spin1
.byte >_spin2
_skip nop
global_ nop
X_global ldx #$40
X__ dex
bne X__
beq X___
X___ ldx #$41
_X__ dex
bne _X__
nop
anno lda #$42
T106B lda anno
clc
bcc _skip
.word T106B
_skip nop
JMP1 lda JMP1
JMP0 lda JMP0
JMP11 lda JMP11
_JMP lda _JMP
_JMP0 lda _JMP0
_JMP1 lda _JMP1
_JMP2 lda _JMP2
jmp1 lda jmp1
Jmp1 lda Jmp1
BRA lda BRA
brl lda brl
LDAL .byte $af
.byte $95
.byte $10
.byte $00
nop
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
plain_DUP1 .var $11
X_under1_DUP1 .var $12
X__dub1 .var $13
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 plain_DUP1
lda X_under1_DUP1
lda X__dub1
_plain lda _plain
plain lda plain
global8 dex
bne plain
X_under1 lda X_under1
_X__dub1 lda _X__dub1
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
X_under1_DUP1 .var $22
lda plain_DUP1
lda X_under1_DUP1
rts