6502bench/SourceGen/SGTestData/Expected/20052-branches-and-banks_acme.S

;ACME can't handle 65816 code that lives outside bank zero
*       =       $0000
        !pseudopc $1000 {
        !hex    18fbe2305c000044000102cf000044af000044ad0000a50030f562b2ffd0b082
        !hex    a9ff1700170044cfc0ff44f005303c8239005c0020002c0020f41700f44400d0
        !hex    03dc0810ea201220201520200f20225634125c103254cf1032548006eaea6016
        !hex    3254af163254af7d3254af163254af7d3254ad1732ad1532ad7e32ad7c32ea20
        !hex    1632201732201832207d32207e32207f32eaa200fc1932fc7a32206e32207132
        !hex    206832206b3220743220773280187c19327c7a326c08106c0810dc0810dc0810
        !hex    7d3254eaea60200e20eac23008a90000e230a90028a9eaeae23008a900c230a9
        !hex    000028a9eaeac230ea6b
        } ;!pseudopc
Finish ACME v0.96.4 support There's no easy way to make non-zero-bank 65816 code work, so I'm punting and just generating a whole-file hex dump for those. This renders tests 2007 and 2009 useless, so I'm hesitant to claim that ACME support is fully functional. 2019-08-04 21:48:42 +00:00			`;ACME can't handle 65816 code that lives outside bank zero`
Fix ACME code gen "overflow" ACME has a "real" PC and a "pseudo" PC. The "real" PC determines the initial position in a 64KB buffer used to hold assembler output. If the amount of code generated runs off the end, the assembler fails with "produced too much code". The source code generator in SourceGen was outputting a "real" PC for the first address range and "psuedo" PCs for any address ranges that followed. This produced nice results for code with a single range, but caused problems for multi-range sources if the initial range was high in memory and a later range was lower in memory. While the assembler isn't actually generating more than 64KB of code, ACME's buffer management was detecting an overflow. Now, if a source file has multiple address ranges, we set the "real" PC to $0000 and use a "pseudo" PC for all ranges. Output for projects with a single address range is unmodified. 2020-05-14 23:37:33 +00:00			`* = $0000`
			`!pseudopc $1000 {`
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			`!hex 18fbe2305c000044000102cf000044af000044ad0000a50030f562b2ffd0b082`
			`!hex a9ff1700170044cfc0ff44f005303c8239005c0020002c0020f41700f44400d0`
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			`!hex 03dc0810ea201220201520200f20225634125c103254cf1032548006eaea6016`
			`!hex 3254af163254af7d3254af163254af7d3254ad1732ad1532ad7e32ad7c32ea20`
			`!hex 1632201732201832207d32207e32207f32eaa200fc1932fc7a32206e32207132`
			`!hex 206832206b3220743220773280187c19327c7a326c08106c0810dc0810dc0810`
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			`!hex 7d3254eaea60200e20eac23008a90000e230a90028a9eaeae23008a900c230a9`
			`!hex 000028a9eaeac230ea6b`
Fix ACME code gen "overflow" ACME has a "real" PC and a "pseudo" PC. The "real" PC determines the initial position in a 64KB buffer used to hold assembler output. If the amount of code generated runs off the end, the assembler fails with "produced too much code". The source code generator in SourceGen was outputting a "real" PC for the first address range and "psuedo" PCs for any address ranges that followed. This produced nice results for code with a single range, but caused problems for multi-range sources if the initial range was high in memory and a later range was lower in memory. While the assembler isn't actually generating more than 64KB of code, ACME's buffer management was detecting an overflow. Now, if a source file has multiple address ranges, we set the "real" PC to $0000 and use a "pseudo" PC for all ranges. Output for projects with a single address range is unmodified. 2020-05-14 23:37:33 +00:00			`} ;!pseudopc`