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

;ACME can't handle 65816 code that lives outside bank zero
*       =       $1000
        !hex    18fbe2305c000044000102cf000044af000044ad0000a50030f562b2ffd0b082
        !hex    a9ff1700170044cfc0ff44f005303c8239005c0020002c0020f41700f44400d0
        !hex    03dc0810ea201220201520200f20225634125c103254cf1032548006eaea6016
        !hex    3254af163254af7d3254af163254af7d3254ad1732ad1532ad7e32ad7c32ea20
        !hex    1632201732201832207d32207e32207f32eaa200fc1932fc7a32206e32207132
        !hex    206832206b3220743220773280187c19327c7a326c08106c0810dc0810dc0810
        !hex    7d3254eaea60200e20eac23008a90000e230a90028a9eaeae23008a900c230a9
        !hex    000028a9eaeac230eaad0e20ad2220200e20202220fc0e20d0037c0e2020cbed
        !hex    adcbedd0037ccbedea6b
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 14:48:42 -07:00			`;ACME can't handle 65816 code that lives outside bank zero`
ORG rework, part 1 This is the first step toward changing the address region map from a linear list to a hierarchy. See issue #107 for the plan. The AddressMap class has been rewritten to support the new approach. The rest of the project has been updated to conform to the new API, but feature-wise is unchanged. While the map class supports nested regions with explicit lengths, the rest of the application still assumes a series of non-overlapping regions with "floating" lengths. The Set Address dialog is currently non-functional. All of the output for cc65 changed because generation of segment comments has been removed. Some of the output for ACME changed as well, because we no longer follow "* = addr" with a redundant pseudopc statement. ACME and 65tass have similar approaches to placing things in memory, and so now have similar implementations. 2021-09-16 17:02:19 -07:00			`* = $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-06 17:30:50 -07: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-01 17:59:12 -07: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 11:54:00 -07:00			`!hex 7d3254eaea60200e20eac23008a90000e230a90028a9eaeae23008a900c230a9`
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 13:47:04 -07:00			`!hex 000028a9eaeac230eaad0e20ad2220200e20202220fc0e20d0037c0e2020cbed`
			`!hex adcbedd0037ccbedea6b`