Closed ecm-bitflipper closed 2 years ago
Thanks. At first glance that looks like a compiler bug
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. :-)
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
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...
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
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.
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.
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.
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: @.***>
[1] https://github.com/EtchedPixels/CC6303/issues/21#issuecomment-1209285747 [2] https://github.com/notifications/unsubscribe-auth/ADHZ2EH4EM5P4XJARZH74SDVYJBTTANCNFSM5557EPGQ
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:
Which I then pared back to this to run it through cc68:
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:
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.