Some 16-bit operands are tracked internally as 24-bit, appending the
B (data bank) or K (program bank) register to form the full address.
For some assemblers the K-bank instructions must be output as 24-bit
values, even for 16-bit JMP/JSR, but for most we want to strip the
bank byte off before outputting the operand as hex or decimal.
This expands 20032-labels-and-symbols with a mix of 24-bit, 16-bit+B,
and 16-bit+K instructions formatted in various ways. No existing
tests were affected by this change.
(issue #172)
We were treating PEA's operand as an absolute address and attempting to
extend it to 24 bits. This wasn't very successful, and was
counter-productive when the argument was actually a constant, which is
common. Worse, if the operand appeared to reference an internal address
outside bank 0, we would output a 24-bit value, breaking 64tass and cc65.
We now treat PEA as having an immediate operand. (It was already
classified as an "extended immediate", but the operand-address
computation was still happening.)
This will have little to no effect on projects that use OMF relocation
data, because PEA arguments are explicitly identified as symbols or
constants.
New tests were added to 20032-labels-and-symbols to exercise the code
generation failures. A few other tests that used PEA were affected.
20152-local-variables was fixed by adding a symbolic reference, the
others remained as-is and the expected output was revised.
(issue #172)
The existing workaround for broken Merlin 32 behavior is sufficient
to handle the new test cases. This updates 20032-labels-and-symbols
to fully exercise all DP addressing modes with non-DP labels.
(issue #170)
Most assemblers treat '<' and '>' as byte-select operators. Merlin 32
treats them as shift operators, making '<' effectively a no-op. A
mask is applied based on the length implied by the opcode or pseudo-op,
e.g. "DFB <FOO" will mask off the high bits. This is problematic for
instructions like "LDA <FOO", where the choice between absolute and DP
addressing depends on the value of "<FOO". If FOO is >= $100, the
lack of masking will cause it be treated as absolute. There is
currently no other mechanism to force the use of a direct-page opcode.
The only recourse is to append "&$ff" to the operand, so the
assembler knows that it can be handled as a DP op. The code generator
has been updated to add "&$ff" where needed, based on the label's
value. Unfortunately the assembler doesn't accept this for certain
specific addressing modes; this appears to be a bug.
The relevant test cases (2003x-labels-and-symbols) have been updated
to exercise these situations. The current test projects side-step the
failing assembler behavior by using a DP label instead. These should
be changed to correctly exercise the full behavior, with the code
generator outputting the instructions as raw hex values to work
around bugs.
There are some deliberately broken things (like a duplicate label) in
the 20030 case that were copied into the 20032 case when it was
created. For ease of editing these have been removed from 20032.
(issue #170)
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)
Andy McFadden