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.
The 65816 definition makes it a two-byte instruction, like COP. On
the 6502 it acted like a two-byte instruction, but in practice very
few assemblers treat it that way. Very few humans, for that matter.
So it's now treated as a single byte instruction, with the following
byte encoded as a data value.
This worked, sort of. The problem is that SourceGen will revert to
hex output in certain situations, such as a broken symbolic
reference. There happens to be one in the ZIPPY example, and it's
on a relative branch.
The goal with the segment stuff is to allow cc65 to treat the
source as relocatable code. In that context, a relative branch to
an absolute address doesn't make any sense, so the assembler reports
a range error.
We don't currently have a mechanism that guarantees no references
are broken (and no affordance for finding them), so we can't make
this mode the default yet.
Instead, we continue to use the generic config, but generate the
correct set of lines as comments.
(issue #39)
These *almost* match what cc65 has, and are accepted as primary or
aliases by 64tass.
This combines the LAX and LXA operations. LXA is the immediate
form of LAX, and behaves somewhat differently (and is unstable).
I was treating them as two separate operations with independent
mnemonics, but that doesn't seem to be the preferred way to
handle it.
The cc65 generator wasn't generating LAX before; now it does. This
required nudging the width disambiguator, as LAX is a second
example of an instruction with both DP,Y and ABS,Y operands.
(issue #20)
