6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-03 05:49:48 +00:00
Code Issues Projects Releases Wiki Activity
fa1b0af932
6502bench/SourceGen/SGTestData/Expected/20042-address-changes_64tass.S

125 lines
2.5 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"
Fix 64tass output for non-loadable files 64tass wants to place its output into a 64KB region of memory, starting at the address "*" is set to, and continuing without wrapping around the end of the bank. Some files aren't meant to be handled that way, so we need to generate the output differently. If the file's output fits nicely, it's considered "loadable", and is generated in the usual way. If it doesn't, it's treated as "streamable", and the initial "* = addr" directive is omitted (leaving "*" at zero), and we go straight to ".logical" directives. 65816 code with an initial address outside bank 0 is treated as "streamable" whether or not the contents fit nicely in the designated 64K area. This caused a minor change to a few of the 65816 tests. A new test, 20240-large-overlay, exercises "streamable" by creating a file with eight overlapping 8KB segments that load at $8000. While the file as a whole fits in 64KB, it wouldn't if loaded at the desired start address. Also, updated the regression test harness to report assembler failure independently of overall test failure. This makes it easier to confirm that (say) ACME v0.96.4 still works with the code we generate, even though it doesn't match the expected output (which was generated for v0.97). (problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
.logical $021000
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
.as
.xs
clc
xce
sep #$ff
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
jsr L21100
jsr L21107
jmp L22000
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 64tass output for non-loadable files 64tass wants to place its output into a 64KB region of memory, starting at the address "*" is set to, and continuing without wrapping around the end of the bank. Some files aren't meant to be handled that way, so we need to generate the output differently. If the file's output fits nicely, it's considered "loadable", and is generated in the usual way. If it doesn't, it's treated as "streamable", and the initial "* = addr" directive is omitted (leaving "*" at zero), and we go straight to ".logical" directives. 65816 code with an initial address outside bank 0 is treated as "streamable" whether or not the contents fit nicely in the designated 64K area. This caused a minor change to a few of the 65816 tests. A new test, 20240-large-overlay, exercises "streamable" by creating a file with eight overlapping 8KB segments that load at $8000. While the file as a whole fits in 64KB, it wouldn't if loaded at the desired start address. Also, updated the regression test harness to report assembler failure independently of overall test failure. This makes it easier to confirm that (say) ACME v0.96.4 still works with the code we generate, even though it doesn't match the expected output (which was generated for v0.97). (problem was raised in issue #98)
2021-08-02 00:09:52 +00:00
.here
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $021100
L21100 bit L21100 & $ffff
L21103 lda #$11
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
ldx #$11
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
L21107 ldy #$11
per L21103
bra L21103
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
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $021100
_L21100_0 bit _L21100_0 & $ffff
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
lda #$22
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
_L21105 ldx #$22
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
ldy #$22
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
per _L21105
jmp _L21105
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
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $021100
_L21100_1 bit _L21100_1 & $ffff
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
lda #$33
ldx #$33
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
_L21107_0 ldy #$33
per _L21107_0
bra _L21107_0
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
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $022000
L22000 bit L22000 & $ffff
beq $022018
bra _L22020
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
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $022020
_L22020 bit _L22020 & $ffff
beq $022029
brl _L22080
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
_offend nop
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
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $022080
_L22080 bit _L22080 & $ffff
lda _offend & $ffff
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
jsr _offend
Allow explicit widths in project/platform symbols, part 3 Implement multi-byte project/platform symbols by filling out a table of addresses. Each symbol is "painted" into the table, replacing an existing entry if the new entry has higher priority. This allows us to handle overlapping entries, giving boosted priority to platform symbols that are defined in .sym65 files loaded later. The bounds on project/platform symbols are now rigidly defined. If the "nearby" feature is enabled, references to SYM-1 will be picked up, but we won't go hunting for SYM+1 unless the symbol is at least two bytes wide. The cost of adding a symbol to the symbol table is about the same, but we don't have a quick way to remove a symbol. Previously, if two platform symbols had the same value, the symbol with the alphabetically lowest label would win. Now, the symbol defined in the most-recently-loaded file wins. (If you define two symbols with the same value in the same file, it's still resolved alphabetically.) This allows the user to pick the winner by arranging the load order of the platform symbol files. Platform symbols now keep a reference to the file ident of the symbol file that defined them, so we can show the symbols's source in the Info panel. These changes altered the behavior of test 2008-address-changes, which includes some tests on external addresses that are close to labeled internal addresses. The previous behavior essentially treated user labels as being 3 bytes wide and extending outside the file bounds, which was mildly convenient on occasion but felt a little skanky. (We could do with a way to define external symbols relative to internal symbols, for things like the source address of code that gets relocated.) Also, re-enabled some unit tests. Also, added a bit of identifying stuff to CrashLog.txt.
2019-10-02 23:26:05 +00:00
lda $2029
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
jsr $022029
lda 0+(_L22080 & $ffff)-1
jsr _L22080-1
lda _L22080 & $ffff
jsr _L22080
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
lda $00
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
beq _L22100
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 $ad
.here
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $022100
_L22100 nop
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
nop
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
jmp _L23000
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
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $022800
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 $00
.byte $28
.fill 14,$00
.here
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $022820
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
.fill 18,$00
.here
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $023000
_L23000 bit _L23000 & $ffff
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
lda #$44
ldx #$44
ldy #$44
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
brl _fwd
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
_ulabel .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
.here
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $023100
Tweak "nearby" label finder The code that found a nearby data target for an instruction operand was searching backward but not forward. We now take one step forward, so that "LDA TABLE-1,Y" fills in automatically. This altered 2008-address-changes, which had just this situation. It didn't alter 2010-target-adjustment, but the existing tests were insufficient and have been improved.
2019-10-30 01:12:22 +00:00
.byte $02
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
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
_fwd bit _fwd & $ffff
lda _ulabel & $ffff
lda 0+(_ulabel & $ffff)+1
Allow explicit widths in project/platform symbols, part 3 Implement multi-byte project/platform symbols by filling out a table of addresses. Each symbol is "painted" into the table, replacing an existing entry if the new entry has higher priority. This allows us to handle overlapping entries, giving boosted priority to platform symbols that are defined in .sym65 files loaded later. The bounds on project/platform symbols are now rigidly defined. If the "nearby" feature is enabled, references to SYM-1 will be picked up, but we won't go hunting for SYM+1 unless the symbol is at least two bytes wide. The cost of adding a symbol to the symbol table is about the same, but we don't have a quick way to remove a symbol. Previously, if two platform symbols had the same value, the symbol with the alphabetically lowest label would win. Now, the symbol defined in the most-recently-loaded file wins. (If you define two symbols with the same value in the same file, it's still resolved alphabetically.) This allows the user to pick the winner by arranging the load order of the platform symbol files. Platform symbols now keep a reference to the file ident of the symbol file that defined them, so we can show the symbols's source in the Info panel. These changes altered the behavior of test 2008-address-changes, which includes some tests on external addresses that are close to labeled internal addresses. The previous behavior essentially treated user labels as being 3 bytes wide and extending outside the file bounds, which was mildly convenient on occasion but felt a little skanky. (We could do with a way to define external symbols relative to internal symbols, for things like the source address of code that gets relocated.) Also, re-enabled some unit tests. Also, added a bit of identifying stuff to CrashLog.txt.
2019-10-02 23:26:05 +00:00
lda $300e
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
lda $300f
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
lda 0+(_fwd & $ffff)-1
beq _L23182
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 $ea
.byte $ea
.here
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $023180
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 $00
.byte $01
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
_L23182 bit _L23182 & $ffff
lda _label1 & $ffff
lda 0+(_label1 & $ffff)+1
lda 0+(_label1 & $ffff)+112
bra _L23200
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
_label1 .byte $ea
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 $ea
.here
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
.logical $023200
_L23200 bit _L23200 & $ffff
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 $00
.byte $01
.here
Reference in New Issue Copy Permalink