Issue with little CRC-16 program compilation? about cc6303 HOT 9 CLOSED

Thanks. At first glance that looks like a compiler bug

from cc6303.

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. :-)

from cc6303.

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

from cc6303.

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...

from cc6303.

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

from cc6303.

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.

from cc6303.

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.

from cc6303.

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.

from cc6303.

from cc6303.