6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-11-30 01:50:10 +00:00
Code Issues Projects Releases Wiki Activity
bac9949d8a
6502bench/SourceGen/SGTestData/Expected/2019-local-variables_acme.S

230 lines
5.7 KiB
ArmAsm
Raw Normal View History

Handle variable labels that are duplicates of non-variables After thrashing around a bit, I had to choose between making the uniquifier more complicated, or making de-duplication a separate step. Since I don't really expect duplicates to be a thing, I went with the latter. Updated the regression test.
2019-09-01 04:54:20 +00:00
;Edited to have duplicate labels (PROJ_ZERO, DPCODE).
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
!cpu 65816
Change some EQU handling Changed the sort order on EQU lines so that constants come before address definitions. This caused trivial changes to three of the regression tests. Added the ability to jump directly to an EQU line when an opcode is double-clicked on.
2019-10-10 20:49:21 +00:00
CONST_ZERO = $f0 ;project const
Add a blank line between constants and addresses In the assembler output, add a blank line between the constants and addresses in the long list of equates. The earlier change that corrected the BIT instruction caused test 2009-branches-and-banks to fail, because it was relying on the idea that BIT made the carry flag indeterminate. Changing a BCC to a BVS restored the desired behavior.
2019-10-23 05:43:10 +00:00
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
PROJ_ZERO = $00 ;project addr
PROJ_ONE = $01 ;project addr
Fix ACME code gen "overflow" ACME has a "real" PC and a "pseudo" PC. The "real" PC determines the initial position in a 64KB buffer used to hold assembler output. If the amount of code generated runs off the end, the assembler fails with "produced too much code". The source code generator in SourceGen was outputting a "real" PC for the first address range and "psuedo" PCs for any address ranges that followed. This produced nice results for code with a single range, but caused problems for multi-range sources if the initial range was high in memory and a later range was lower in memory. While the assembler isn't actually generating more than 64KB of code, ACME's buffer management was detecting an overflow. Now, if a source file has multiple address ranges, we set the "real" PC to $0000 and use a "pseudo" PC for all ranges. Output for projects with a single address range is unmodified.
2020-05-14 23:37:33 +00:00
* = $0000
!pseudopc $1000 {
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
!as
!rs
ldy PROJ_ZERO
lda (PROJ_ONE),y
Apply project/platform symbols to Numeric/Address data operands A ".dd2 <address>" item would get linked to an internal label, but references to external addresses weren't doing the appropriate search through the platform/project symbol list. This change altered the output of the 2019-local-variables test. The previous behavior was restored by disabling "nearby" symbol matching in the project properties. Updated the "lookup symbol by address" function to ignore local variables. Also, minor updates to Applesoft and F8-ROM symbol tables.
2019-09-15 21:19:45 +00:00
sta $03 ;could be PROJ_ONE+2, but "nearby" is off
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
ldx $04
lda CONST_ZERO,S
sta $f1,S
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
!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
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
ldx $04
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
lda .CONST_ZERO_VAR,S
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
sta $f1,S
eor 0
ora 240,S
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
!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
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
.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
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
.CONST_ZERO_VAR = $f0
lda .VAR_THREE
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
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
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
lda $11
lda+1 DPCODE
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
!zone Z00002c
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
ldx PROJ_ZERO
ldx PROJ_ONE
ldx $02
bit $ffa9
ldy PROJ_ZERO
ldy PROJ_ONE
ldy $02
!byte $2c
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
!zone Z00003c
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
L103C lda #$fe
beq L103C
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
ldy .NH0
ldy .NH1
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
ldy $02
nop
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
!zone Z000047
.NH0 = $00 ;not hidden
.NH1 = $01 ;not hidden
.PTR0 = $10
.CONST0 = $10
lda .PTR0
ldx .PTR0+1
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
ldy $12
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
lda (.CONST0,S),y
sta (.CONST0+3,S),y
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
;Test name redefinition. This is mostly of interest for assemblers without
;redefinable variables, but also of interest to the cross-reference window.
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
!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
Work around two assembler issues Most assemblers end local label scope when a global label is encountered. cc65 takes this one step further by ending local label scope when constants or variables are defined. So, if we have a variable table with a nonzero number of entries, we want to create a fake global label at that point to end the scope. Merlin 32 won't let you write " LDA #',' ". For some reason the comma causes an error. IGenerator now has a "tweak operand format" interface that lets us fix that.
2019-09-20 21:05:17 +00:00
@PTR_1 nop
Implement local variables for ACME Unlike 64tass and Merlin, which allow you to redefine symbols, ACME uses "zones" that provide scope for local variables. This means that, at the point of a local variable table definition, we have to start a new zone and output the full set of active symbols, not just the newly-defined ones. (If you set the "clear previous" flag in the LvTable there's no difference.) We could do a bit better by only outputting the symbols that are actually used within the zone, similar to what we do for global project/platform symbols, but that's a bunch of work for questionable benefit.
2019-09-01 17:55:19 +00:00
!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
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
lda+1 DPCODE
jsr DPCODE
rts
Fix ACME code gen "overflow" ACME has a "real" PC and a "pseudo" PC. The "real" PC determines the initial position in a 64KB buffer used to hold assembler output. If the amount of code generated runs off the end, the assembler fails with "produced too much code". The source code generator in SourceGen was outputting a "real" PC for the first address range and "psuedo" PCs for any address ranges that followed. This produced nice results for code with a single range, but caused problems for multi-range sources if the initial range was high in memory and a later range was lower in memory. While the assembler isn't actually generating more than 64KB of code, ACME's buffer management was detecting an overflow. Now, if a source file has multiple address ranges, we set the "real" PC to $0000 and use a "pseudo" PC for all ranges. Output for projects with a single address range is unmodified.
2020-05-14 23:37:33 +00:00
} ;!pseudopc
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
!pseudopc $0080 {
DPCODE nop
lda+1 DPCODE
lda+2 DPCODE
lda+3 DPCODE
Work around two assembler issues Most assemblers end local label scope when a global label is encountered. cc65 takes this one step further by ending local label scope when constants or variables are defined. So, if we have a variable table with a nonzero number of entries, we want to create a fake global label at that point to end the scope. Merlin 32 won't let you write " LDA #',' ". For some reason the comma causes an error. IGenerator now has a "tweak operand format" interface that lets us fix that.
2019-09-20 21:05:17 +00:00
@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
Add 2019-local-variables test This hits most of the edge cases, but doesn't exercise the two duplicate name situations (var name same as user label, var name same as project/platform symbol). Also, fixed a bug in the EditDefSymbol uniqueness check where it was comparing a symbol to itself.
2019-09-01 03:32:43 +00:00
rts
} ;!pseudopc
Reference in New Issue Copy Permalink