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
bdad8501f0
6502bench/SourceGen/SGTestData/Expected/20052-branches-and-banks_64tass.S

152 lines
2.7 KiB
ArmAsm
Raw Normal View History

Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
.cpu "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
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
longsym = $123456
* = $1000
.as
.xs
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
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +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
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
.byte $01
.byte $02
.logical $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
Improve Common expression generation Removed unnecessary parenthesis from Common-style expressions, which are used by 64tass and ACME.
2020-07-02 20:00:02 +00:00
lda @wL440000 & $ffff
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
lda zero
bmi L440004
per high44
bne high44
brl L44FFC0
Improve Common expression generation Removed unnecessary parenthesis from Common-style expressions, which are used by 64tass and ACME.
2020-07-02 20:00:02 +00:00
dat44 .word dat44 & $ffff
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
.long dat44
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
.here
.logical $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
bmi L440004
brl L440004
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00: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
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
.here
.logical $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
Improve Common expression generation Removed unnecessary parenthesis from Common-style expressions, which are used by 64tass and ACME.
2020-07-02 20:00:02 +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]
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +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
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +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
.here
.logical $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 .long backchk
L54321C lda backchk
lda fwdchk
lda $543216
lda $54327d
lda 0+(backchk & $ffff)+1
lda 0+(backchk & $ffff)-1
lda 0+(fwdchk & $ffff)+1
lda 0+(fwdval & $ffff)+2
nop
jsr backchk
jsr backchk+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 $543218
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
jsr fwdchk+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 $54327f
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,x)
jsr (fwdval,x)
jsr _L54326E
jsr _L543271
jsr _L543268
jsr _L54326B
jsr _L543274
jsr _L543277
bra L543280
_L543268 jmp (backval,x)
_L54326B jmp (fwdval,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 .long 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
Fix 64tass code gen corner case On the 65816, if you say "JSR foo" from bank $12, but "foo" is an address in bank 0, most assemblers will conclude that you're forming a 16-bit argument with a 16-bit address and assemble happily. 64tass halts with an error. Up until v1.55 or so, you could fake it out by supplying a large offset. This no longer works. The preferred way to say "no really I mean to do this" is to append ",k" to the operand. We now do that as needed. I didn't want to define a new ExpressionMode for 64tass just to support an operand modifier that should probably never actually get generated (you can't call across banks with JSR!), so this is implemented with a quirk and an op flag. 64tass v1.56.2625 is now the default. (issue #104)
2021-08-09 20:47:04 +00:00
L543280 jsr skip,k
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
.al
.xl
php
lda #$0000
sep #$30
.as
.xs
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
.al
.xl
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 64tass code gen corner case On the 65816, if you say "JSR foo" from bank $12, but "foo" is an address in bank 0, most assemblers will conclude that you're forming a 16-bit argument with a 16-bit address and assemble happily. 64tass halts with an error. Up until v1.55 or so, you could fake it out by supplying a large offset. This no longer works. The preferred way to say "no really I mean to do this" is to append ",k" to the operand. We now do that as needed. I didn't want to define a new ExpressionMode for 64tass just to support an operand modifier that should probably never actually get generated (you can't call across banks with JSR!), so this is implemented with a quirk and an op flag. 64tass v1.56.2625 is now the default. (issue #104)
2021-08-09 20:47:04 +00:00
lda skip
lda skip+20
jsr skip,k
jsr skip+20,k
jsr (skip,k,x)
bne _L5432B7
jmp (skip,k,x)
_L5432B7 jsr $54edcb
lda $edcb
bne _L5432C2
jmp ($54edcb,x)
_L5432C2 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
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
.here
Reference in New Issue Copy Permalink