6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-11 13:50:13 +00:00
Code Issues Projects Releases Wiki Activity
7a7ff44d3a
6502bench/SourceGen/SGTestData/Expected/20290-region-isolation_cc65.S

250 lines
4.4 KiB
ArmAsm
Raw Normal View History

Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
.setcpu "6502"
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
THREE_K = $3000 ;project symbol test
IN_1 = $9000
IN_2 = $a000
IN_3 = $b000
IN_4 = $c000
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
.org $0800
jsr region1
jsr region2
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
jsr THREE_K
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
jsr $4000
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
lda L9005
lda LA008
lda IN_3+11
lda IN_4+14
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
self: .byte $ad,$ea
L081A: nop
jsr altbnk1
jsr altbnk2
jmp done
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
altbnk1: bit $ffc0
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
lda self+1
bne L081A
rts
.org *+$0000
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
altbnk2: bit $ffc0
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
lda $0819
bne $081a
ldx $081b
rts
.org $0839
done: nop
rts
.res 197,$00
.org $1000
region1x: lda region1x
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
rts
.res 202,$00
.org $1000
region1: lda region1
pha
ldy #$11
nop
@copy: lda inner1_pre,y
sta inner1,y
dey
bpl @copy
bit $101d
jsr inner1
jmp finish1
inner1_pre:
.org $9000
inner1: ldx inner1
ldy #$aa
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
L9005: ldy finish1
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
ldy finish2
ldy $302b
ldy $402b
rts
.org $102b
finish1: ldy finish1
ldx region1
ldx region2
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
ldx THREE_K
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
ldx $4000
lda inner1
lda inner2
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
lda IN_3
lda IN_4
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
pla
rts
.res 184,$00
.org $2000
region2: lda region2
pha
ldy #$11
nop
@copy: lda inner2_pre,y
sta inner2,y
dey
bpl @copy
bit $201d
jsr inner2
jmp finish2
inner2_pre:
.org $a000
inner2: ldx inner2
ldy #$aa
ldy $102b
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
LA008: ldy finish2
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
ldy $302b
ldy $402b
rts
.org $202b
finish2: ldy finish2
ldx $1000
ldx region2
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
ldx THREE_K
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
ldx $4000
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
lda IN_1
lda inner2
lda IN_3
lda IN_4
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
pla
rts
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
.res 184,$00
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
.org $3000
region3: lda region3
pha
ldy #$11
nop
@copy: lda inner3_pre,y
sta inner3,y
dey
bpl @copy
bit $301d
jsr inner3
jmp finish3
inner3_pre:
.org $b000
inner3: ldx inner3
ldy #$aa
ldy finish1
ldy finish2
ldy finish3
ldy $402b
rts
.org $302b
finish3: ldy finish3
ldx region1
ldx region2
ldx region3
ldx $4000
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
lda inner1
lda inner2
lda inner3
lda IN_4
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
pla
rts
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
.res 184,$00
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
.org $4000
region4: lda region4
pha
ldy #$11
nop
@copy: lda inner4_pre,y
sta inner4,y
dey
bpl @copy
bit $401d
jsr inner4
jmp finish4
inner4_pre:
.org $c000
inner4: ldx inner4
ldy #$aa
ldy $102b
ldy $202b
ldy $302b
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
_checkit: ldy finish4
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
rts
.org $402b
finish4: ldy finish4
ldx $1000
ldx $2000
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
ldx THREE_K
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
ldx region4
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
lda IN_1
lda IN_2
lda IN_3
lda inner4
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
pla
rts
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
.res 184,$00
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
.org $0000
.byte $ff
Reference in New Issue Copy Permalink