search

EtchedPixels / CC6303

A C compiler for the 6800 series processors
Other
37 stars 7 forks source link

Issue with little CRC-16 program compilation? #21

Closed ecm-bitflipper closed 2 years ago

ecm-bitflipper commented 2 years ago

Hi EtchedPixels,

You asked me to open this as a bug on your github page for the project. I'm hoping to add a CRC-16 routine to an old 6800 based 1987 car computer. I started with this little program:

#include <stdio.h>
#include <stdlib.h>

#define CRC16 0xa001

unsigned short calc_crc(unsigned char *data, char size)
{
unsigned short crc = 0;
short i;
    while(size--){
        crc ^= *data++;
        for(i = 0; i < 8; i++)
            crc = (crc&1) ? (crc>>1)^CRC16 : (crc>>1);
    }
    return crc;         
}

int main(int argc, char **argv)
{
    if (argc < 3) exit(-1);
    unsigned short crc = calc_crc(argv[1], atoi(argv[2]));
    printf("%04X\n", crc);

}

Which I then pared back to this to run it through cc68:

#define CRC16 0xa001

void calc_crc()
{
unsigned char *data = 0x6000;
unsigned char size = 0xDD;
unsigned short crc = 0x7654;
char i;
    while(size--){
        crc ^= *data++;
        for(i = 0; i < 8; i++)
            crc = (crc&1) ? (crc>>1)^CRC16 : (crc>>1);
    }
}

I only put those values as the defaults for the variables so I knew which was which in the assembly as so I could set them appropriately post compilation.

I fixed up the assembly so that exorsim is happy with it:

L0002   EQU    $2200
L0004   EQU    $2202
L0006   EQU    $2204
L0008   EQU    $2206
TMP     EQU    $2208
TMP1    EQU    $220A
        ORG  $2800
CALCCRC LDAA #$24 * START ADDRESS MSB
    CLRB      * END ADDRESS MSB
    STAA L0002
    STAB L0002+1
    CLRA
    LDAB #$0A * DATA LENGTH
    STAB L0004
    LDAA #$00 * CRC MSB
    LDAB #$00 * CRC LSB
    STAA L0006
    STAB L0006+1
    JMP L000B
L0009   LDAA L0006
    LDAB L0006+1
    PSHB
    PSHA
    LDAA L0002
    LDAB L0002+1
    STAA TMP1
    STAB TMP1+1
    ADDB #$01
    ADCA #$00
    STAA L0002
    STAB L0002+1
    LDAA TMP1
    LDAB TMP1+1
    STAA TMP
    STAB TMP+1
    LDX TMP
    CLRA
    LDAB $00,X
    TSX
    EORB $00+1,X
    EORA $00,X
    INS
    INS
    STAA L0006
    STAB L0006+1
    CLRA
    CLRB
    STAB L0008
L000F   CLRA
    LDAB L0008
    CMPB #$08
    JSR BOOLULT
    BNE L0012
    JMP L0010
L0012   LDAA L0006
    LDAB L0006+1
    CLRA
    ANDB #$01
    STAA TMP1
    ORAB TMP1
    BEQ L001A
    LDAA L0006
    LDAB L0006+1
    LSRA
    RORB
    EORB #$01
    EORA #$A0
    JMP L001D
L001A   LDAA L0006
    LDAB L0006+1
    LSRA
    RORB
L001D   STAA L0006
    STAB L0006+1
L0011   CLRA
    LDAB L0008
    INC L0008
    JMP L000F
L0010
L000B   CLRA
    LDAB L0004
    DEC L0004
    TSTB
    BNE L9999
L000A
L0001   RTS
L9999   JMP L0009
BOOLULT LDAB    #0
        TBA
        ROLB
        RTS

Steps to reproduce:

Exorsim:

https://github.com/jhallen/exorsim

Best to get one of the latest commits because otherwise the source needs to be tweaked to eliminate some conflicts. You probably already have it. I built it in cygwin.

Create a text file called 1234567890.txt and put 1234567890 in it.

Then in your cygwin window:

./exor --mon

a 0

[Paste in the assembly above]

read 1234567890.txt 2400

x 2800

d 2200

When I run the full program in cygwin like so:

$ ./testcrc 1234567890 10 C57A

I get a CRC-16 as shown. I was expecting to find the CRC at 2206/2207 in exorsim, but it seems all its doing is counting to 8? I wish I knew if I'm doing something wrong or if I've hit a bug in cc6303.

EtchedPixels commented 2 years ago

Thanks. At first glance that looks like a compiler bug

ecm-bitflipper commented 2 years ago

Hey, no need to thank me, worst case scenario I can rest easy knowing I wasn't completely foolish, best case scenario you fix it and I get a 6800 CRC-16 routine. :-)

EtchedPixels commented 2 years ago

I'm confused as to the relationship between the C code and the asm you have though - they don't appear to be directly related as the C generates lots of foo,X which you don't have

ecm-bitflipper commented 2 years ago

I did see that in a few other attempts that I made with more extensive code snippits, however, this particular routine does not generate any of those. This is the untouched output from cc68:

I had to adjust the code slightly, taking the @ out of TMP and TMP1, changing all the JEQ and JNE to BEQ and BNE because exorsim doesn't understand them, one branch as a result required that L9999 to turn it into a JMP because it was more than 128 bytes away...

That said, I was going to paste in the untouched output and noticed that I lost a couple of pieces like the PULX's at L0001 I'm going to pour over it more closely to make sure I didn't drop anything else. Will let you know...

ecm-bitflipper commented 2 years ago

I should have checked my work before posting my last update. I forgot to add the command line parameters to get the raw output again. The untouched assembly from cc68 with the correct command line parameters matches logic wise to what I pasted above.

So just ignore the last paragraph in my previous update. The rest still explains what I had to do for exorsim to be okay with the code.

$ cc68 -Cl --cpu 6800 testcrc6800.c
testcrc6800.c(5): Warning: Converting integer to pointer without a cast
;
; File generated by cc68 v 2.18
;
        .setcpu         6800
        .export         _calc_crc
        .code
        .export _calc_crc
_calc_crc:
        ldaa #$60
        clrb
        staa L0002
        stab L0002+1
        clra
        ldab #$DD
        stab L0004
        ldaa #$76
        ldab #$54
        staa L0006
        stab L0006+1
        jmp L000B
L0009:
        ;invalid XDP
        ldaa L0006
        ldab L0006+1
        pshb
        psha
        ldaa L0002
        ldab L0002+1
        staa @tmp1
        stab @tmp1+1
        addb #$01
        adca #$00
        staa L0002
        stab L0002+1
        ldaa @tmp1
        ldab @tmp1+1
        staa @tmp
        stab @tmp+1
        ldx @tmp
        clra
        ldab $00,x
        tsx
        eorb $00+1,x
        eora $00,x
        ins
        ins
        staa L0006
        stab L0006+1
        clra
        clrb
        stab L0008
        ;invalid DP
L000F:
        clra
        ldab L0008
        cmpb #$08
        jsr boolult
        jne L0012
        jmp L0010
L0012:
        ;invalid XDP
        ldaa L0006
        ldab L0006+1
        clra
        andb #$01
        staa @tmp1
        orab @tmp1
        jeq L001A
        ldaa L0006
        ldab L0006+1
        lsra
        rorb
        eorb #$01
        eora #$A0
        jmp L001D
L001A:
        ldaa L0006
        ldab L0006+1
        lsra
        rorb
L001D:
        staa L0006
        stab L0006+1
        ;invalid XDP
L0011:
        clra
        ldab L0008
        inc L0008
        jmp L000F
L0010:
L000B:
        clra
        ldab L0004
        dec L0004
        tstb
        jne L0009
L000A:
L0001:
        rts
        .code
        .data
        .bss
L0002:
        .blkb   2
L0004:
        .blkb   1
L0006:
        .blkb   2
L0008:
        .blkb   1
EtchedPixels commented 2 years ago

Yep - the included assembler for the compiler uses JNE etc as a directive that turns into either BNE or BEQ 3 JMP xx so that you have to worry about spacing. The @ is used to indicate direct page.

EtchedPixels commented 2 years ago

Finally had a chance to look at it - the CRC is computed correctly but your modified coded doesn't return crc, so the CRC is not copied into AB before the return. So not it turns out a compiler bug.

ecm-bitflipper commented 2 years ago

I know it's not your intention to debug assembler code modified from what cc68 produces so I will leave this alone if it doesn't get a response. I need the code to be in the modified format in order to embed it into the car ECM EPROM. Maybe you could give it a second set of eyes and point out where I went wrong? When I run it in exorsim and then do

d 2200

I don't see anything close to a checksum in memory. I'm really stumped where I went wrong. Thank you for confirming it's not a compiler bug in any case.

ecm-bitflipper commented 1 year ago

Hey, no need to thank me, worst case scenario I can rest easy knowing I wasn't completely foolish, best case scenario you fix it and I get a 6800 CRC-16 routine. :-)

Dylan.

On 2022-08-09 04:57, EtchedPixels wrote:

Thanks. At first glance that looks like a compiler bug

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/EtchedPixels/CC6303/issues/21#issuecomment-1209285747 [2] https://github.com/notifications/unsubscribe-auth/ADHZ2EH4EM5P4XJARZH74SDVYJBTTANCNFSM5557EPGQ