6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2026-04-22 01:16:42 +00:00
Code Issues Projects Releases Wiki Activity

Finish ACME v0.96.4 support

Browse Source 
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.
This commit is contained in:
Andy McFadden
2019-08-04 14:48:42 -07:00
parent 71badf2359
commit d80132e941
22 changed files with 3093 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SourceGen/RuntimeData/Help/codegen.html
+58 -15
View File
@@ -24,9 +24,10 @@ for each.</p>
<p>SourceGen currently supports the following cross-assemblers:</p>
<ul>
<li><a href="https://sourceforge.net/projects/tass64/">64tass</a> v1.53.1515 or later</li>
<li><a href="https://cc65.github.io/">cc65</a> v2.17 or later</li>
<li><a href="https://www.brutaldeluxe.fr/products/crossdevtools/merlin/">Merlin 32</a> v1.0.0 or later</li>
<li><a href="#64tass">64tass</a></li>
<li><a href="#acme">ACME</a></li>
<li><a href="#cc65">cc65</a></li>
<li><a href="#merlin32">Merlin 32</a></li>
</ul>
@@ -124,7 +125,8 @@ code, but also needs to know how to handle the corner cases.</p>
<h3><a name="64tass">64tass</a></h3>
<p>Code is generated for 64tass v1.53.1515.</p>
<p>Code is generated for 64tass v1.53.1515 or later.
<a href="https://sourceforge.net/projects/tass64/">[web site]</a></p>
<p>Bugs:</p>
<ul>
@@ -157,16 +159,52 @@ code, but also needs to know how to handle the corner cases.</p>
</ul>
<h3><a name="cc65">cc65</a></h3>
<h3><a name="acme">ACME</a></h3>
<p>Code is generated for cc65 v2.27.</p>
<p>Code is generated for ACME v0.96.4 or later.
<a href="https://sourceforge.net/projects/acme-crossass/">[web site]</a></p>
<p>Bugs:</p>
<ul>
<li>The arguments to MVN/MVP are reversed.</li>
<li>The "pseudo PC" is only 16 bits, so any 65816 code targeted to run
outside bank zero cannot be assembled. SourceGen currently deals with
this by outputting the entire file as a hex dump.</li>
<li>Undocumented opcode $AB (<code>LAX #imm</code>) generates an error.</li>
</ul>
<p>Quirks:</p>
<ul>
<li>The assembler shares some traits with one-pass assemblers. In
particular, if you forward-reference a zero-page label, the reference
generates a 16-bit absolute address instead of an 8-bit zero-page
address. Unlike other one-pass assemblers, the width is "sticky",
and backward references appearing later in the file also use absolute
addressing even though the proper width is known at that point. This is
worked around by using explicit "force zero page" annotations on
all references to zero-page labels.</li>
<li>Undocumented opcode <code>ALR</code> ($4b) uses mnemonic
<code>ASR</code> instead.</li>
<li>Officially, the preferred file extension for ACME source code is ".a",
but this is already used on UNIX systems for static libraries (which
means shell file completion tends to ignore it). Since ".S" is pretty
universally recognized as assembly source, code generated by SourceGen
for ACME also uses ".S".</li>
</ul>
<h3><a name="cc65">cc65</a></h3>
<p>Code is generated for cc65 v2.17 or v2.18.
<a href="https://cc65.github.io/">[web site]</a></p>
<p>Bugs:</p>
<ul>
<li>The arguments to <code>MVN</code>/<code>MVP</code> are reversed (v2.17)
or zeroed (v2.18).</li>
<li>PC relative branches don't wrap around at bank boundaries.</li>
<li>BRK &lt;arg&gt; is assembled to opcode $05 rather than $00.</li>
<li>WDM is not supported.</li>
<li>[fixed in v2.18] <code>BRK &lt;arg&gt;</code> is assembled to opcode
$05 rather than $00.</li>
<li>[fixed in v2.18] <code>WDM</code> is not supported.</li>
</ul>
<p>Quirks:</p>
@@ -182,9 +220,9 @@ code, but also needs to know how to handle the corner cases.</p>
other opcodes match up with the "unintended opcodes" document.</li>
<li>ca65 is implemented as a single-pass assembler, so label widths
can't always be known in time. For example, if you use some zero-page
labels, but they're defined via .ORG $0000 after the point where the
labels are used, the assembler will already have generated them as
absolute values. Width disambiguation must be applied to operands
labels, but they're defined via <code>.ORG $0000</code> after the point
where the labels are used, the assembler will already have generated them
as absolute values. Width disambiguation must be applied to operands
that wouldn't be ambiguous to a multi-pass assembler.</li>
<li>The assembler is geared toward generating relocatable code with
multiple segments (it is, after all, an assembler for a C compiler).
@@ -195,7 +233,10 @@ code, but also needs to know how to handle the corner cases.</p>
<h3><a name="merlin32">Merlin 32</a></h3>
<p>Code is generated for Merlin 32 v1.0.</p>
<p>Code is generated for Merlin 32 v1.0.
<a href="https://www.brutaldeluxe.fr/products/crossdevtools/merlin/">[web site]</a>
<a href="https://github.com/apple2accumulator/merlin32/issues">[bug tracker]</a>
</p>
<p>Bugs:</p>
<ul>
@@ -227,9 +268,11 @@ code, but also needs to know how to handle the corner cases.</p>
but doesn't attempt to track the emulation flag. So if you issue a
<code>REP #$20</code>
while in emulation mode, the assembler will incorrectly assume long
registers. (Really I just want to be able to turn the width-tracking
off, but there's no way to do that.)</li>
registers. Ideally it would be possible to configure that off, but
there's no way to do that, so instead we occasionally generate
additional width directives.</li>
<li>Non-unique local labels should cause an error, but don't.</li>
<li>No undocumented opcodes are supported.</li>
</ul>
</div>