You are not logged in.
Lost Password?


Register To Post



 Bottom   Previous Topic   Next Topic

#11
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/5/10 20:43
Nintendoid!
Joined 2007/12/14
169 Posts
CoderLong Time User (12 Years) App Coder
One of the members here already started on an implementation of LLVM/v810... Maybe it was Parasyte? dasi? As I recall there wasn't much progress on it.
Top

#12
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/5/13 22:40
Virtual Freak
Joined 2014/8/31
USA
83 Posts
Long Time User (5 Years)App Coder
Quote:

blitter wrote:
Off the top of my head:

1) Biggest problem so far is that GCCVB 4.x will sometimes generate relative jumps that are offset by some power of two ahead of where their proper destination should be. This becomes a huge problem when these jumps are executed repeatedly, as eventually the PC will wrap and wind up in video memory or elsewhere. I wrote a tool that operates on the final .elf file and attempts to correct these bogus jumps, but it's more of a bandaid than a solution. http://www.planetvb.com/modules/newbb ... t_id=31203#forumpost31203

3) Found a bug recently in the version of gas that ships with GCCVB 4.x where sometimes a bne instruction-- written in the assembly source *as a bne instruction*-- will assemble to a be and a jr instruction. There is no reason whatsoever that I can think of why this should happen.

I found a valid reason for 3): Branch instructions have a 9-bit displacement. Relative jumps have a 26-bit displacement. If it's necessary to jump further than +/-256 bytes, you'll have to do something like: be/jr.

As for 1), I haven't looked into it, but is it possible that the gas port doesn't take into account jumps that span further than +/-32MB? I don't think GCC would know/care about that information. But binutils certainly would.
Top

#13
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/5/14 6:59
Nintendoid!
Joined 2007/12/14
169 Posts
CoderLong Time User (12 Years) App Coder
Quote:

cr1901 wrote:
I found a valid reason for 3): Branch instructions have a 9-bit displacement. Relative jumps have a 26-bit displacement. If it's necessary to jump further than +/-256 bytes, you'll have to do something like: be/jr.


Derp. Looking at the v810 architecture manual, you are absolutely right. On the bright side, that's one less bug to fix in GCC. :)
Top

#14
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/5/14 15:56
Virtual Freak
Joined 2014/8/31
USA
83 Posts
Long Time User (5 Years)App Coder
Yes, I'm glad I could fix a bug by recognizing that it is, in fact, not a bug :P. I do understand why it could be seen as a bug. I haven't taken a look at the .md as to why this particular code sequence is generated.

Since a repeated JMP misses its destination by a power of two, I can't help but wonder if that is related to the jump range of -/+32MB...
Top

#15
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/5/15 8:46
Virtual Freak
Joined 2014/8/31
USA
83 Posts
Long Time User (5 Years)App Coder
Okay, I'm officially confused now as to what GCC 4.2 is thinking here...

Consider the following code- loadfail.c:

#include "libgccvb/libgccvb.h"

void test_load()
{
    
WA[31].head WRLD_END;
}


-O0 produces the following:

.file    "loadfail.c"
    
.section .text
    
.align 2
    
.global _test_load
    
.type    _test_load, @function
_test_load:
    
add -4,sp
    st
.w r29,0[sp]
    
mov sp,r29
    movhi hi
(_WA),r0,r10
    movea lo
(_WA),r10,r10
    ld
.w 0[r10],r10
    addi 992
,r10,r10
    movea lo
(64),r0,r11
    st
.h r11,0[r10]
    
mov r29,sp
    ld
.w 0[sp],r29
    add 4
,sp
    jmp 
[r31]
    .
size    _test_load, .-_test_load
    
.ident    "GCC: (GNU) 4.4.2"


Makes sense to me. -O1 to -O3 however, produce something rather weird to me.

.file    "loadfail.c"
    
.section .text
    
.align 2
    
.global _test_load
    
.type    _test_load, @function
_test_load:
    
movhi hi(_WA),r0,r10
    ld
.w lo(_WA)[r10],r10
    movea lo
(64),r0,r11
    st
.h r11,992[r10]
    
jmp [r31]
    .
size    _test_load, .-_test_load
    
.ident    "GCC: (GNU) 4.4.2"

Maybe it's because it's 4:30AM, but I can see how a load from a control register address (since _WA=0x0003D800, r10 holds 0x00030000 by the time ld.w lo(_WA) rolls around...) is going to help to get the right address of the World Attributes base register into r10 by any stretch of the imagination.

This isn't a fluke either. By -O2, all address loads in all files seem to be replaced with this optimized form. I can't really test right now, but doing a load from memory to generate a base address (instead of using movea) seems wrong. Can anyone possibly explain why this works?

EDIT: Wait a second, it's in the unoptimized version too!

ld
.w 0[r10],r10
addi 992
,r10,r10

WHY is there a load to r10?! There's absolutely no guarantee that _WA will be 0, and the addi might generate a bad address!
Top

#16
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/5/15 22:34
Nintendoid!
Joined 2012/8/5
USA
117 Posts
CoderLong Time User (7 Years) PVBCC 2013 3rd
My two cents is I agree. Makes no sense. Also I've been compiling one of my projects with -O so I tried it with -O2 and it stops working. No errors just no output from the same code that works fine with -O. I haven't dug into it at all but the -O2 optimizations clearly break what I'm working on. Doesn't really explain anything but might be some evidence that there is a bug there.
Top

#17
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/5/15 23:53
Virtual Freak
Joined 2014/8/31
USA
83 Posts
Long Time User (5 Years)App Coder
FWIW, in my test code, O3 works correctly in Mednafen. So whatever that ld.w is doing doesn't seem to be breaking anything. Won't be able to test real hardware until later.
Top

 Top   Previous Topic   Next Topic


Register To Post