Last visit was: Fri Nov 01, 2024 12:04 am
|
It is currently Fri Nov 01, 2024 12:04 am
|
Porting the C64 compiler to target OPC5 (or OPC6)
| Author |
Message |
|
BigEd
Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1803
|
Dave's current programs start with this: Code: void init() {
asm {
ORG 0x100
mov r15, r0, _main
};
} Perhaps that could be implicit, and it would then jump over all the storage locations for free?
|
| Sat Aug 12, 2017 7:55 am |
|
|
|
hoglet
Joined: Tue Feb 10, 2015 7:07 am
Posts: 52
|
Hi Rob, A few incompatibilities with gcc have crept back in. Here's a pull request to fix them: https://github.com/robfinch/Cores/pull/2I'm still getting incorrect code generation in at least one case: 14. Incorrect code generation with a * 2 - 1Code: int bug14() {
int a = 123;
int b = a * 2 - 1;
return b;
}
Code: _bug14:
push r13,r14
push r12,r14
mov r12,r14
dec r14,2
mov r5,r0,123
sto r5,r12,-1
ld r7,r12,-1
mov r6,r7
add r6,r6
sub r5,r6,1 # this is incorrect; should be sub r6, r0, 1; mov r5, r6
sto r5,r12,-2
ld r5,r12,-2
mov r1,r5
mov r14,r12
pop r12,r14
pop r13,r14
mov r15,r13
Dave
|
| Sat Aug 12, 2017 10:00 am |
|
|
|
hoglet
Joined: Tue Feb 10, 2015 7:07 am
Posts: 52
|
I'm still seeing core dumps; here's a minimal test case. 15. Core dump with expression a + a - 1Code: int bug15() {
int a = 123;
int b = a + a - 1;
return b;
}
Code: dmb@quadhog:~/atom/opc/examples/pi-spigot-c$ ./c64 bug15.c
Segmentation fault (core dumped)
dmb@quadhog:~/atom/opc/examples/pi-spigot-c$ gdb ./c64 core
Core was generated by `./c64 bug15.c'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0804e0b2 in GenerateBinary (node=0x96781fc, flags=1, size=1, op=0) at CodeGenerator.cpp:947
947 ap3->isAddress = ap1->isAddress | ap2->isAddress;
(gdb) bt
#0 0x0804e0b2 in GenerateBinary (node=0x96781fc, flags=1, size=1, op=0) at CodeGenerator.cpp:947
#1 0x080518df in GenerateExpression (node=0x96781fc, flags=1, size=1) at CodeGenerator.cpp:2154
#2 0x0804dda0 in GenerateBinary (node=0x9678254, flags=1039, size=1, op=3) at CodeGenerator.cpp:905
#3 0x08051905 in GenerateExpression (node=0x9678254, flags=1039, size=1) at CodeGenerator.cpp:2155
#4 0x0805081d in GenerateAssign (node=0x96782ac, flags=1039, size=1) at CodeGenerator.cpp:1737
#5 0x08051ce9 in GenerateExpression (node=0x96782ac, flags=1039, size=1) at CodeGenerator.cpp:2196
#6 0x08056fb8 in Statement::GenerateCompound (this=0x9677fe4) at GenerateStatement.cpp:671
#7 0x080570b4 in Statement::Generate (this=0x9677fe4) at GenerateStatement.cpp:713
#8 0x0805ee4d in GenerateFunction (sym=0x809b350 <compiler+42160>) at OPC6.cpp:560
#9 0x080719a4 in ParseFunctionBody (sp=0x809b350 <compiler+42160>) at ParseFunction.cpp:468
#10 0x0807137a in ParseFunction (sp=0x809b350 <compiler+42160>) at ParseFunction.cpp:336
#11 0x08067585 in Declaration::declare (parent=0x0, table=0x808f180 <gsyms>, al=2, ilc=0, ztype=28) at ParseDeclarations.cpp:1385
#12 0x08067b40 in GlobalDeclaration::Parse (this=0x9677a44) at ParseDeclarations.cpp:1527
#13 0x08052eb5 in Compiler::compile (this=0x8090ea0 <compiler>) at Compiler.cpp:104
#14 0x0804b6ea in main (argc=1, argv=0xbfabce48) at Cmain.cpp:82
(gdb) p ap1
$1 = (AMODE *) 0x96787a4
(gdb) p ap2
$2 = (AMODE *) 0x0
(gdb) p ap3
$3 = (AMODE *) 0x967878c
(gdb) quit
Dave
|
| Sat Aug 12, 2017 10:11 am |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2205
Location: Canada
|
Re: bug 15
There are space characters in the file with the most significant bit set making it a negative character.
Apparently the isdigit() routine doesn't like that. I could strip the high bit off of characters as they come in. But are they part of a MBCS or wide characters and should be kept ?
Is 'C' coded coded in just stand ascii 7 bit characters or are other characters allowed ? Eg. comments.
Interestingly, the MS isdigit() routine gets called instead of the isdigit() routine coded in the program. As it is in the program it doesn't care and would've worked.
I'm guessing roughly the same isdigit() routine is used in gcc.
What to do about character over $7F ?
_________________Robert Finch http://www.finitron.ca
|
| Sat Aug 12, 2017 11:43 am |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2205
Location: Canada
|
Re: org$100 Quote: Perhaps that could be implicit, and it would then jump over all the storage locations for free? The compiler could spit out an "org $100" at the start of code if that would help. But how smart is the assembler ? Can it rearrange where the variables are or does it care ? The compiler could spit out an "org $4000" at the beginning to locate the vars at $4000. But if it's org'd at $4000 can the assembler handle the code being org'd to $100 afterwards ? eg. org $4000 vars org $100 code _________________Robert Finch http://www.finitron.ca
|
| Sat Aug 12, 2017 12:50 pm |
|
|
|
hoglet
Joined: Tue Feb 10, 2015 7:07 am
Posts: 52
|
robfinch wrote: Re: bug 15
There are space characters in the file with the most significant bit set making it a negative character.
Apparently the isdigit() routine doesn't like that. I could strip the high bit off of characters as they come in. But are they part of a MBCS or wide characters and should be kept ?
Is 'C' coded coded in just stand ascii 7 bit characters or are other characters allowed ? Eg. comments.
Interestingly, the MS isdigit() routine gets called instead of the isdigit() routine coded in the program. As it is in the program it doesn't care and would've worked.
I'm guessing roughly the same isdigit() routine is used in gcc.
What to do about character over $7F ? There are no unusual characters in the file: Code: od -Ax -tx1 bug15.c
000000 69 6e 74 20 62 75 67 31 35 28 29 20 7b 0a 20 20
000010 20 69 6e 74 20 61 20 3d 20 31 32 33 3b 0a 20 20
000020 20 69 6e 74 20 62 20 3d 20 61 20 2b 20 61 20 20
000030 2d 20 31 3b 0a 20 20 20 72 65 74 75 72 6e 20 62
000040 3b 0a 7d 0a
000044
The file is attached: Can you not reproduce this? (i.e. are you suggesting it is a Linux only bug?) Dave
You do not have the required permissions to view the files attached to this post.
|
| Sat Aug 12, 2017 12:56 pm |
|
|
|
hoglet
Joined: Tue Feb 10, 2015 7:07 am
Posts: 52
|
I've updated to the latest compiler version that fixed bug14. I'm getting a new issue now... 16. Incorrect store address of array writeI'm having an issue with the code generated from this fragment: Code: for (i = len; i > 0; i--)
{
x = 10 * pi[i]+ q * i;
pi[i] = x % (2 * i - 1);
q = x / (2 * i - 1);
}
Code: 018e pi_25:
018e 2a03 cmp r3,r0
018f d00f 01ca mi.mov r15,r0,pi_26
0191 2a03 cmp r3,r0
0192 500f 01ca z.mov r15,r0,pi_26
0194 28e5 push r5,r14
0195 10c5 fea8 mov r5,r12,-344
0197 0037 mov r7,r3
0198 0457 add r7,r5
0199 0777 ld r7,r7
019a 1005 000a mov r5,r0,10
019c 0071 mov r1,r7
019d 0052 mov r2,r5
019e 190d 0334 jsr r13,r0,__mul
01a0 0016 mov r6,r1
01a1 17c5 fff9 ld r5,r12,-7
01a3 0051 mov r1,r5
01a4 0032 mov r2,r3
01a5 190d 0334 jsr r13,r0,__mul
01a7 0017 mov r7,r1
01a8 0065 mov r5,r6
01a9 0475 add r5,r7
01aa 0054 mov r4,r5
01ab 29e5 pop r5,r14
01ac 10c6 fea8 mov r6,r12,-344
01ae 0035 mov r5,r3
01af 0465 add r5,r6 # r5 contains address of pi[i]
01b0 28e5 push r5,r14 # save r5
01b1 0035 mov r5,r3 # r5 now a working register
01b2 0455 add r5,r5
01b3 0057 mov r7,r5
01b4 1a07 0001 sub r7,r0,1
01b6 0041 mov r1,r4
01b7 0072 mov r2,r7
01b8 190d 0338 jsr r13,r0,__mod
01ba 0651 sto r1,r5 # result stored back to garbage address
01bb 29e5 pop r5,r14 # pop address of pi[i] back off the stace
01bc 0037 mov r7,r3
01bd 0477 add r7,r7
01be 0076 mov r6,r7
01bf 1a06 0001 sub r6,r0,1
01c1 0041 mov r1,r4
01c2 0062 mov r2,r6
01c3 190d 0336 jsr r13,r0,__div
01c5 16c1 fff9 sto r1,r12,-7
01c7 0e13 dec r3,1
01c8 100f 018e mov r15,r0,pi_25
It seems like the instructions at 1ba and 1bb are the wrong way around. Edit: manually swapping them and the program runs successfully. Dave
|
| Sat Aug 12, 2017 1:28 pm |
|
|
|
Revaldinho
Joined: Tue Apr 25, 2017 7:33 pm
Posts: 32
|
Quote: The compiler could spit out an "org $100" at the start of code if that would help. But how smart is the assembler ? Can it rearrange where the variables are or does it care ?
The compiler could spit out an "org $4000" at the beginning to locate the vars at $4000. But if it's org'd at $4000 can the assembler handle the code being org'd to $100 afterwards ?
eg.
org $4000
vars
org $100
Rob, yes the assembler will deal with this. You can have multiple ORG statements and they can be out of order. (Python syntax for hex is 0x1234 rather than $1234) R
|
| Sat Aug 12, 2017 1:43 pm |
|
|
|
hoglet
Joined: Tue Feb 10, 2015 7:07 am
Posts: 52
|
Hi Rob, Another compiler issue, this time with using longs. I've reduced it to a simple test case that fails. 17. GenerateTempRegPop():register still in useCode: void bug17() {
long a, b;
a = 1;
b = (a*10)/3;
}
Code: ./c64 bug17.c
GenerateTempRegPop():register still in use
Dave
|
| Sat Aug 12, 2017 1:49 pm |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2205
Location: Canada
|
Re: unusual characters
I cut and paste the sample from the forum. So there may have been extra garbage added. In any case I was able to reproduce the bug with the bug15 file.
Dave, I just wanted to say I appreciate all the testing you're doing.
_________________Robert Finch http://www.finitron.ca
|
| Sat Aug 12, 2017 2:53 pm |
|
|
|
hoglet
Joined: Tue Feb 10, 2015 7:07 am
Posts: 52
|
robfinch wrote: Dave, I just wanted to say I appreciate all the testing you're doing.
And we very much appreciate the efforts you are putting into an OPC6 C Compiler. It's also been a great opportunity to use the debugger in the PiTubeDirect OPC6 Co Processor in anger. This actually makes finding issues pretty painless. It supports break points / watch points on code execution, memory reads and memory writes. You can single step, dump registers, disassemble., dump memory. etc. Memory watch points, for example, have been invaluable in tracking stuff writing to the wrong address. Dave
You do not have the required permissions to view the files attached to this post.
Last edited by hoglet on Sat Aug 12, 2017 4:28 pm, edited 1 time in total.
|
| Sat Aug 12, 2017 4:23 pm |
|
|
|
BigEd
Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1803
|
(Dave, it would be handy, I think, if you could share a couple of screenshots of the debugger in action? The forum copes poorly with very large embedded images, but if you just attach them it will make a thumbnail)
|
| Sat Aug 12, 2017 4:28 pm |
|
|
|
hoglet
Joined: Tue Feb 10, 2015 7:07 am
Posts: 52
|
BigEd wrote: (Dave, it would be handy, I think, if you could share a couple of screenshots of the debugger in action? The forum copes poorly with very large embedded images, but if you just attach them it will make a thumbnail) The process is as follows.... 1. Run the compiler and assembler, which produces srecords Attachment: opc6debug0.png 2. Switch to a serial console into the BBC Micro (9600 baud) and use the srec command to upload the srecords (just cut and paste!) Attachment: opc6debug1.png 3. Switch to a second serial console into the PiTubeDirect debugger (115,200 baud), and do some debugging! Attachment: opc6debug2.png the memory watchpoint firing above is a sign the the code as corrupted itself. The offending instruction was at 0x01ba. Attachment: opc6debug3.png the assembler listing comes in handy as well. Code: 018e pi_25:
018e 2a03 cmp r3,r0
018f d00f 01ca mi.mov r15,r0,pi_26
0191 2a03 cmp r3,r0
0192 500f 01ca z.mov r15,r0,pi_26
0194 28e5 push r5,r14
0195 10c5 fea8 mov r5,r12,-344
0197 0037 mov r7,r3
0198 0457 add r7,r5
0199 0777 ld r7,r7
019a 1005 000a mov r5,r0,10
019c 0071 mov r1,r7
019d 0052 mov r2,r5
019e 190d 0334 jsr r13,r0,__mul
01a0 0016 mov r6,r1
01a1 17c5 fff9 ld r5,r12,-7
01a3 0051 mov r1,r5
01a4 0032 mov r2,r3
01a5 190d 0334 jsr r13,r0,__mul
01a7 0017 mov r7,r1
01a8 0065 mov r5,r6
01a9 0475 add r5,r7
01aa 0054 mov r4,r5
01ab 29e5 pop r5,r14
01ac 10c6 fea8 mov r6,r12,-344
01ae 0035 mov r5,r3
01af 0465 add r5,r6
01b0 28e5 push r5,r14
01b1 0035 mov r5,r3
01b2 0455 add r5,r5
01b3 0057 mov r7,r5
01b4 1a07 0001 sub r7,r0,1
01b6 0041 mov r1,r4
01b7 0072 mov r2,r7
01b8 190d 0338 jsr r13,r0,__mod
01ba 0651 sto r1,r5
01bb 29e5 pop r5,r14
This is the full command set of the debugger: Attachment: opc6debug4.png In PiTubeDirect it was about a days work to add OPC6 support: - a C emulation of the CPU ( opc6.c) - an implemention of the PiTubeDirect debug interface ( opc6_debug.c), which describes the CPU to a generic debugger - a Co Processor wrapper for the CPU ( copro-opc6.c) (this is pretty much boiler plate code) Dave
You do not have the required permissions to view the files attached to this post.
|
| Sat Aug 12, 2017 4:58 pm |
|
|
|
BigEd
Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1803
|
That's excellent Dave - thanks!
|
| Sat Aug 12, 2017 5:04 pm |
|
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am
Posts: 2205
Location: Canada
|
There's a fix for bugs 16,17 now. The fix caused a fair amount of change to the code generated in my test files. Generates smaller code with the fix to boot. I hope I didn't break something else with the fix. I've just been comparing output from one set of test files to the next generation and reviewing the changes. Usually it's only a couple of lines that change.
_________________Robert Finch http://www.finitron.ca
|
| Sat Aug 12, 2017 5:32 pm |
|
Who is online |
Users browsing this forum: No registered users and 0 guests |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum
|
|
