16-bit instructions using program counter relative addressing should use 16-bit offsets

[craigthomas]

Describe the bug
16-bit instructions using program counter relative addressing should use 16-bit offsets by default. Currently only LEAX, LEAY, LEAS and LEAU use the correct behavior. Program counter indexed relative addressing modes for instructions STX, STU, STD, ADDD, CMPX, LDD, LDX, LDU, SUBD, CMPD, CMPS, CMPU, LDS, CMPY, LDY, STS, and STY need to be fixed.

To Reproduce

1. Create a file called test.asm and add the following contents:

                ORG     $3F00
START           STX     1,PCR
                LDA     #$0A
NEXT            RTS
                END     START

2. Assemble the file with:

python3 assembler.py test.asm --print

3. Output will be:

-- Assembled Statements --
$3F00                         ORG $3F00                          ;            
$3F00 AF8C01          START   STX 1,PCR                          ;          
$3F03 860A                    LDA #$0A                           ;   
$3F05 39               NEXT   RTS                                ;       
$3F06                         END START                          ;

Expected behavior
Correct output should be:

-- Assembled Statements --
$3F00                         ORG $3F00                          ;      
$3F00 AF8D0001        START   STX 1,PCR                          ;                  
$3F04 860A                    LDA #$0A                           ;              
$3F06 39               NEXT   RTS                                ;                
$3F07                         END START                          ;  

Desktop (please complete the following information):

• OS: Ubuntu 20.04
• Python Version: 3.8.10

[craigthomas]

After looking at more source code, the initial problem as described above, isn't actually the correct solution. In fact, the example given above is actually correct:

$3F00 AF8C01        START    STX 1,PCR

The post-byte codes of 8C01 is correct, as the 1 can be interpreted as a direct value due to it's size. If the statement were instead:

START    STX $0101,PCR

Then the post-byte code should be 8D0101 as the value is extended. This brings up problems in other areas of the source code as well. Consider the following example:

VAR     FDB 0
        STX <VAR,PCR

In this case even though VAR is technically an extended value, the explicit direct addressing forced by < means that it should be interpreted with 8C instead of 8D. Since direct values are handled by an explicit Operand class, that means the above statement throws an error. Fundamentally, structural design decisions regarding the handling of direct and extended values as Operand classes really need to be refactored to push extended / direct recognition to the Value sub-classes instead.

[craigthomas]

Fixed by PR #54