Ophis/doc/hll1.sgm
2012-06-09 03:21:33 -07:00

186 lines
6.6 KiB
Plaintext

<chapter id="hll-1">
<title>The Second Step</title>
<para>
This essay discusses how to do 16-or-more bit addition and
subtraction on the 6502, and how to do unsigned comparisons
properly, thus making 16-bit arithmetic less necessary.
</para>
<section>
<title>The problem</title>
<para>
The <literal>ADC</literal>, <literal>SBC</literal>, <literal>INX</literal>,
and <literal>INY</literal> instructions are the only real
arithmetic instructions the 6502 chip has. In and of themselves,
they aren't too useful for general applications: the accumulator
can only hold 8 bits, and thus can't store any value over 255.
Matters get even worse when we're branching based on
values; <literal>BMI</literal> and <literal>BPL</literal> hinge on
the seventh (sign) bit of the result, so we can't represent any
value above 127.
</para>
</section>
<section>
<title>The solution</title>
<para>
We have two solutions available to us. First, we can use
the <quote>unsigned</quote> discipline, which involves checking
different flags, but lets us deal with values between 0 and 255
instead of -128 to 127. Second, we can trade speed and register
persistence for multiple precision arithmetic, using 16-bit
integers (-32768 to 32767, or 0-65535), 24-bit, or more.
</para>
<para>
Multiplication, division, and floating point arithmetic are beyond
the scope of this essay. The best way to deal with those is to
find a math library on the web (I
recommend <ulink url="http://www.6502.org/"></ulink>) and use the
routines there.
</para>
</section>
<section>
<title>Unsigned arithmetic</title>
<para>
When writing control code that hinges on numbers, we should always
strive to have our comparison be with zero; that way, no explicit
compare is necessary, and we can branch simply
with <literal>BEQ/BNE</literal>, which test the zero flag.
Otherwise, we use <literal>CMP</literal>.
The <literal>CMP</literal> command subtracts its argument from the
accumulator (without borrow), updates the flags, but throws away
the result. If the value is equal, the result is zero.
(<literal>CMP</literal> followed by <literal>BEQ</literal>
branches if the argument is equal to the accumulator; this is
probably why it's called <literal>BEQ</literal> and not something
like <literal>BZS</literal>.)
</para>
<para>
Intuitively, then, to check if the accumulator is <emphasis>less
than</emphasis> some value, we <literal>CMP</literal> against that
value and <literal>BMI</literal>. The <literal>BMI</literal>
command branches based on the Negative Flag, which is equal to the
seventh bit of <literal>CMP</literal>'s subtract. That's exactly
what we need, for signed arithmetic. However, this produces
problems if you're writing a boundary detector on your screen or
something and find that 192 &lt; 4. 192 is outside of a signed
byte's range, and is interpreted as if it were -64. This will not
do for most graphics applications, where your values will be
ranging from 0-319 or 0-199 or 0-255.
</para>
<para>
Instead, we take advantage of the implied subtraction
that <literal>CMP</literal> does. When subtracting, the result's
carry bit starts at 1, and gets borrowed from if necessary. Let
us consider some four-bit subtractions.
</para>
<programlisting>
C|3210 C|3210
------ ------
1|1001 9 1|1001 9
|0100 - 4 |1100 -12
------ --- ------ ---
1|0101 5 0|1101 -3
</programlisting>
<para>
The <literal>CMP</literal> command properly modifies the carry bit
to reflect this. When computing A-B, the carry bit is set if A
&gt;= B, and it's clear if A &lt; B. Consider the following two
code sequences.
</para>
<programlisting>
(1) (2)
CMP #$C0 CMP #$C0
BMI label BCC label
</programlisting>
<para>
The code in the first column treats the value in the accumulator
as a signed value, and branches if the value is less than -64.
(Because of overflow issues, it will actually branch for
accumulator values between $40 and $BF, even though it *should*
only be doing it for values between $80 and $BF. To see why,
compare $40 to $C0 and look at the result.) The second column
code treats the accumulator as holding an unsigned value, and
branches if the value is less than 192. It will branch for
accumulator values $00-$BF.
</para>
</section>
<section>
<title>16-bit addition and subtraction</title>
<para>
Time to use the carry bit for what it was meant to do. Adding two
8 bit numbers can produce a 9-bit result. That 9th bit is stored
in the carry flag. The <literal>ADC</literal> command adds the
carry value to its result, as well. Thus, carries work just as
we'd expect them to. Suppose we're storing two 16-bit values, low
byte first, in $C100-1 and $C102-3. To add them together and
store them in $C104-5, this is very easy:
</para>
<programlisting>
CLC
LDA $C100
ADC $C102
STA $C104
LDA $C101
ADC $C103
STA $C105
</programlisting>
<para>
Subtraction is identical, but you set the carry bit first
with <literal>SEC</literal> (because borrow is the complement of
carry&mdash;think about how the unsigned compare works if this
puzzles you) and, of course, using the <literal>SBC</literal>
instruction instead of <literal>ADC</literal>.
</para>
<para>
The carry/borrow bit is set appropriately to let you continue,
too. As long as you just keep working your way up to bytes of
ever-higher significance, this generalizes to 24 (do it three
times instead of two) or 32 (four, etc.) bit integers.
</para>
</section>
<section>
<title>16-bit comparisons</title>
<para>
Doing comparisons on extended precision values is about the same
as doing them on 8-bit values, but you have to have the value you
test in memory, since it won't fit in the accumulator all at once.
You don't have to store the values back anywhere, either, since
all you care about is the final state of the flags. For example,
here's a signed comparison, branching to <literal>label</literal>
if the value in $C100-1 is less than 1000 ($03E8):
</para>
<programlisting>
SEC
LDA $C100
SBC #$E8
LDA $C101 ; We only need the carry bit from that subtract
SBC #$03
BMI label
</programlisting>
<para>
All the commentary on signed and unsigned compares holds for
16-bit (or higher) integers just as it does for the 8-bit
ones.
</para>
</section>
</chapter>