1
0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-05 03:49:53 +00:00
Commit Graph

67 Commits

Author SHA1 Message Date
Andy McFadden
a4f5d19295 Improve 64tass output
DCI is handled with the ".shift" pseudo-op.  The .null, .ptext,
and .shift operators all work correctly with escaped characters,
so we no longer redo those.
2019-08-09 19:13:58 -07:00
Andy McFadden
dae76d9b45 Rework string operand formatting
This generalizes the string pseudo-operand formatter, moving it into
the Asm65 library.  The assembly source generators have been updated
to use it.  This makes the individual generators simpler, and by
virtue of avoiding "test runs" should make them slightly faster.

This also introduces byte-to-character converters, though we're
currently still only supporting low/high ASCII.

Regression test output is unchanged.
2019-08-09 17:46:33 -07:00
Andy McFadden
0d0854bda7 Change the way string formats are defined
We used to use type="String", with the sub-type indicating whether
the string was null-terminated, prefixed with a length, or whatever.
This didn't leave much room for specifying a character encoding,
which is orthogonal to the sub-type.

What we actually want is to have the type specify the string type,
and then have the sub-type determine the character encoding.  These
sub-types can also be used with the Numeric type to specify the
encoding of character operands.

This change updates the enum definitions and the various bits of
code that use them, but does not add any code for working with
non-ASCII character encodings.

The project file version number was incremented to 2, since the new
FormatDescriptor serialization is mildly incompatible with the old.
(Won't explode, but it'll post a complaint and ignore the stuff
it doesn't recognize.)

While I was at it, I finished removing DciReverse.  It's still part
of the 2005-string-types regression test, which currently fails
because the generated source doesn't match.
2019-08-07 16:19:13 -07:00
Andy McFadden
1ad9caa783 First pass at ACME support
I managed to work around most of the quirks, but there's still an
issue with 65816 code.

Also, enabled word wrapping in the AsmGen text boxes.
2019-08-03 20:54:07 -07:00
Andy McFadden
98914e9f80 Treat BRK as a 1-byte instruction
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.
2019-08-02 17:21:50 -07:00
Andy McFadden
c64f72d147 Move WPF code from SourceGenWPF to SourceGen 2019-07-20 13:28:37 -07:00
Andy McFadden
e3906e021b Move WinForms code to SourceGenWF 2019-07-20 13:02:54 -07:00
Andy McFadden
2065f4ef9e Attempt to generate segment names for cc65
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)
2018-11-18 15:11:29 -08:00
Andy McFadden
5b1dde290a Show assembler options in header comment 2018-11-03 14:02:52 -07:00
Andy McFadden
a88c746419 Work around cc65 single-pass behavior
The cc65 assembler runs in a single pass, which means forward
address references default to 16 bits.  For zero-page references
we have to add an explicit width disambiguator.  (This is an
unusual situation that only occurs if you have a zero-page .ORG
in the file after code that references it.)

With this change, 2014-label-dp passes, and no other regression
tests were affected.

(issue #40)
2018-11-02 15:32:54 -07:00
Andy McFadden
c80be07f73 Work around Merlin 32 instruction parsing bug
The 2014-label-dp test now passes.  Prior regression tests are
unaffected.

Also, renamed an IGenerator interface to more accurately reflect
its role.

(issue #37)
2018-11-02 13:49:27 -07:00
Andy McFadden
7aa3e4dbcd Show "assembling" when assembling
Merlin 32 is slow enough with a 64K data file that you have
enough time to read the text.
2018-10-30 16:41:56 -07:00
Andy McFadden
18994ef772 Update comments 2018-10-27 12:46:10 -07:00
Andy McFadden
a8af7e8794 Improve the "common" expression formatter
To avoid confusing the assembler, expressions with a leading
parenthesis like "(foo & $ffff) + 1" are prefixed with a "0+".  This
is not necessary if the operand begins with a '#'.

(issue #16)
2018-10-26 15:45:39 -07:00
Andy McFadden
da91f86043 Get 64tass expressions working
We now insert parenthesis as needed.  This can cause problems in
some situations, so we always prefix parenthetical expressions with
"0+", which looks goofy and is unnecessary for immediate operands.
But it does generate working source code.

Renamed the "simple" expression mode to "common", as it's not
particularly simple but is what you'd expect most assemblers to do.
(OTOH, life has been full of surprises.)

(issue #16)
2018-10-24 14:57:09 -07:00
Andy McFadden
61914c8f79 Progress toward 64tass expression support
Gave cc65 its own expression generator, as the precedence table seems
atypical if not unique.  Configured 64tass to use the "simple"
expression mode.

Added some operations on a 32-bit constant to 2007-labels-and-symbols
to exercise the current worst-case expression (shift + AND + add).
Tweaked the Merlin expression generator to handle it.

(issue #16)
2018-10-24 13:17:03 -07:00
Andy McFadden
f7e5cf2f45 Progress toward 64tass support
Most tests pass, but 2007-labels-and-symbols fails because the
expressions recognized by 64tass don't match up with either of the
other assemblers.

This is currently using a workaround for the local label syntax.
64tass uses '_' as the prefix, which is unfortunate since SourceGen
explicitly allowed underscores in labels.  (So does 64tass for that
matter, but it treats labels specially when the '_' comes first.)
We will need to rename any non-local user labels that start with '_'.

(issue #16)
2018-10-23 20:08:01 -07:00