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)
If an address resolves to a user label in an isolated region, we
don't want to use it. However, we still want to try to match it
to a project/platform symbol.
For example, suppose the isolated code wants to reference address
$1C00, which is a memory-mapped I/O location in one area, but a
regular bunch of code in the other. We don't want it to map to
the regular code, but we do want it to resolve to our table of
platform I/O addresses.
We now handle this correctly. The regression test has been updated
to check this. The current implementation does a linear scan through
the symbol table, but I'm hoping this is not a common situation.
The reference manual has been updated to describe the new feature.
Move the SourceGen manual to a subdirectory in "docs", so that it can
be accessed directly from the 6502bench web site. The place where
it's installed in the distribution doesn't change.
