Last visit was: Wed Oct 09, 2024 7:25 pm
It is currently Wed Oct 09, 2024 7:25 pm



 [ 77 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
 Porting the C64 compiler to target OPC5 (or OPC6) 
Author Message

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1799
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

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/2

I'm still getting incorrect code generation in at least one case:

14. Incorrect code generation with a * 2 - 1
Code:
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

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 - 1
Code:
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

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2187
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 WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2187
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 WWW

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:
Attachment:
bug15.zip

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

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 write

I'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

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

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 use
Code:
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

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2187
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 WWW

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

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1799
(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

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

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1799
That's excellent Dave - thanks!


Sat Aug 12, 2017 5:04 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2187
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 WWW
 [ 77 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

Who is online

Users browsing this forum: CCBot 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

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software