6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-02 13:51:36 +00:00
Code Issues Projects Releases Wiki Activity
e9fbc6c96c
6502bench/SourceGen/SGTestData/Expected/20052-branches-and-banks_cc65.S

139 lines
2.7 KiB
ArmAsm
Raw Normal View History

Initial file commit
2018-09-28 17:05:11 +00:00
.setcpu "65816"
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
zero = $00
Initial file commit
2018-09-28 17:05:11 +00:00
longsym = $123456
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG000"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $1000
.a8
.i8
clc
xce
sep #$30
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
jml L440000
Initial file commit
2018-09-28 17:05:11 +00:00
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
lodat: .byte $00
Initial file commit
2018-09-28 17:05:11 +00:00
.byte $01
.byte $02
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
; .segment "SEG001"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $440000
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
L440000: cmp L440000
L440004: lda L440000
lda a:L440000 & $ffff
lda zero
bmi L440004
Initial file commit
2018-09-28 17:05:11 +00:00
.byte $62,$b2,$ff
.byte $d0,$b0
.byte $82,$a9,$ff
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
dat44: .word dat44 & $ffff
.faraddr dat44
Initial file commit
2018-09-28 17:05:11 +00:00
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
; .segment "SEG002"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $44ffc0
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
L44FFC0: cmp L44FFC0
high44: beq @L44FFCB
Initial file commit
2018-09-28 17:05:11 +00:00
.byte $30,$3c
.byte $82,$39,$00
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
@L44FFCB: jml @L2000
Initial file commit
2018-09-28 17:05:11 +00:00
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
; .segment "SEG003"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $2000
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
@L2000: bit @L2000
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
pea dat44 & $ffff
pea dat44 >> 16
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
bne skip
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
jml [lodat]
Initial file commit
2018-09-28 17:05:11 +00:00
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
skip: nop
Regression test rework, part 4 Split 2005x-branches-and-banks into two parts, one that stays within the 64K bounds of the 6502, one that puts code in a separate bank.
2020-06-07 00:30:50 +00:00
jsr j2
j2: jsr j2+3
jsr j2-3
Initial file commit
2018-09-28 17:05:11 +00:00
jsl longsym
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
jml bank54
; .segment "SEG004"
.org $543210
bank54: cmp bank54
bra L54321C
backchk: nop
nop
Fix 65816 code generation issues Code generated for 64tass was incorrect for JSR/JMP to a location outside the file bounds. A test added to 20052-branches-and-banks revealed an issue with cc65 generation as well.
2020-07-03 20:58:18 +00:00
rts
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
backval: .faraddr backchk
L54321C: lda backchk
lda f:fwdchk
lda $543216
lda $54327d
lda backchk & $ffff +1
lda backchk & $ffff -1
lda fwdchk & $ffff +1
lda fwdval & $ffff +2
nop
jsr backchk & $ffff
jsr backchk & $ffff +1
Fix 65816 code generation issues Code generated for 64tass was incorrect for JSR/JMP to a location outside the file bounds. A test added to 20052-branches-and-banks revealed an issue with cc65 generation as well.
2020-07-03 20:58:18 +00:00
jsr $3218
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
jsr fwdchk & $ffff
jsr fwdchk & $ffff +1
Fix 65816 code generation issues Code generated for 64tass was incorrect for JSR/JMP to a location outside the file bounds. A test added to 20052-branches-and-banks revealed an issue with cc65 generation as well.
2020-07-03 20:58:18 +00:00
jsr $327f
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
nop
ldx #$00
jsr (backval & $ffff,x)
jsr (fwdval & $ffff,x)
jsr @L54326E & $ffff
jsr @L543271 & $ffff
jsr @L543268 & $ffff
jsr @L54326B & $ffff
jsr @L543274 & $ffff
jsr @L543277 & $ffff
bra L543280
@L543268: jmp (backval & $ffff,x)
@L54326B: jmp (fwdval & $ffff,x)
Fix bank for AbsInd and AbsIndLong addressing The Absolute Indirect and Absolute Indirect Long addressing modes (e.g. "JMP (addr)" and "JMP [addr]") are 16-bit values in bank 0. The code analyzer was placing them in the program bank, which meant the wrong symbol was being used. Also, tweak some docs.
2020-07-04 22:03:23 +00:00
@L54326E: jmp (lodat)
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
Fix bank for AbsInd and AbsIndLong addressing The Absolute Indirect and Absolute Indirect Long addressing modes (e.g. "JMP (addr)" and "JMP [addr]") are 16-bit values in bank 0. The code analyzer was placing them in the program bank, which meant the wrong symbol was being used. Also, tweak some docs.
2020-07-04 22:03:23 +00:00
@L543271: jmp (lodat)
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
Fix bank for AbsInd and AbsIndLong addressing The Absolute Indirect and Absolute Indirect Long addressing modes (e.g. "JMP (addr)" and "JMP [addr]") are 16-bit values in bank 0. The code analyzer was placing them in the program bank, which meant the wrong symbol was being used. Also, tweak some docs.
2020-07-04 22:03:23 +00:00
@L543274: jml [lodat]
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
Fix bank for AbsInd and AbsIndLong addressing The Absolute Indirect and Absolute Indirect Long addressing modes (e.g. "JMP (addr)" and "JMP [addr]") are 16-bit values in bank 0. The code analyzer was placing them in the program bank, which meant the wrong symbol was being used. Also, tweak some docs.
2020-07-04 22:03:23 +00:00
@L543277: jml [lodat]
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
fwdval: .faraddr fwdchk
fwdchk: nop
nop
Fix 65816 code generation issues Code generated for 64tass was incorrect for JSR/JMP to a location outside the file bounds. A test added to 20052-branches-and-banks revealed an issue with cc65 generation as well.
2020-07-03 20:58:18 +00:00
rts
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
L543280: jsr skip
Fix 65816 code generation issues Code generated for 64tass was incorrect for JSR/JMP to a location outside the file bounds. A test added to 20052-branches-and-banks revealed an issue with cc65 generation as well.
2020-07-03 20:58:18 +00:00
nop
Change PLP handling The "smart" PLP handler tries to recover the flags from an earlier PHP. The non-smart version just marks all the flags as indeterminate. This doesn't work well on the 65816 in native mode, because having the M/X flags in an indeterminate state is rarely what you want. Code rarely uses PLP to reset the flags to a specific state, preferring explicit SEP/REP. The analyzer is more likely to get the correct answer by simply leaving the flags in their prior state. A test case has been added to 20052-branches-and-banks, which now has "smart PLP" disabled.
2020-07-20 18:54:00 +00:00
rep #$30
.a16
.i16
php
lda #$0000
sep #$30
.a8
.i8
lda #$00
plp
lda #$ea
Fix 65816 code generation issues Code generated for 64tass was incorrect for JSR/JMP to a location outside the file bounds. A test added to 20052-branches-and-banks revealed an issue with cc65 generation as well.
2020-07-03 20:58:18 +00:00
nop
Change PLP handling The "smart" PLP handler tries to recover the flags from an earlier PHP. The non-smart version just marks all the flags as indeterminate. This doesn't work well on the 65816 in native mode, because having the M/X flags in an indeterminate state is rarely what you want. Code rarely uses PLP to reset the flags to a specific state, preferring explicit SEP/REP. The analyzer is more likely to get the correct answer by simply leaving the flags in their prior state. A test case has been added to 20052-branches-and-banks, which now has "smart PLP" disabled.
2020-07-20 18:54:00 +00:00
sep #$30
php
lda #$00
rep #$30
.a16
.i16
lda #$0000
plp
lda #$eaea
rep #$30
Fix 65816 code generation issues Code generated for 64tass was incorrect for JSR/JMP to a location outside the file bounds. A test added to 20052-branches-and-banks revealed an issue with cc65 generation as well.
2020-07-03 20:58:18 +00:00
nop
Fix some 65816 code generation issues Two basic problems: (1) cc65, being a one-pass assembler, can't tell if a forward-referenced label is 16-bit or 24-bit. If the operand is potentially ambiguous, such as "LDA label", we need to add an operand width disambiguator. (The existing tests managed to only do backward references.) (2) 64tass wants the labels on JMP/JSR absolute operands to have 24-bit values that match the current program bank. This is the opposite of cc65, which requires 16-bit values. We need to distinguish PBR vs. DBR instructions (i.e. "LDA abs" vs. "JMP abs") and handle them differently when formatting for "Common". Merlin32 doesn't care, and ACME doesn't work at all, so neither of those needed updating. The 20052-branches-and-banks test was expanded to cover the problematic cases.
2020-07-02 00:59:12 +00:00
rtl
Initial file commit
2018-09-28 17:05:11 +00:00
Reference in New Issue Copy Permalink