2019-11-18 00:05:51 +00:00
|
|
|
.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
|
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
|
|
|
anno lda #$42
|
|
|
|
|
T106B lda anno
|
2019-11-18 00:05:51 +00:00
|
|
|
clc
|
|
|
|
|
bcc _skip
|
|
|
|
|
|
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
|
|
|
.word T106B
|
2019-11-18 00:05:51 +00:00
|
|
|
|
|
|
|
|
_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
|
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
|
|
|
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
|
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
|
|
|
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
|
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 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
|
2019-11-18 00:05:51 +00:00
|
|
|
rts
|
|
|
|
|
|