You are not logged in.
Lost Password?


Register To Post



 Bottom   Previous Topic   Next Topic

#1
Is r29 treated specially / ignored by gccvb? (Bug?)
Posted on: 2010/11/19 4:10
Nintendoid!
Joined 2007/12/14
169 Posts
CoderLong Time User (12 Years) App Coder
Does gccvb intentionally ignore the use of r29 when determining how to assign registers? I'm calling the following function inside a loop and gccvb assigns r29 to the loop's counter in spite of my explicitly assigning r29 in the broken case, and explicitly flagging r29 as clobbered in the latter working case:

#define WHY_DOES_THIS_CRASH
#ifdef WHY_DOES_THIS_CRASH
/* This doesn't work */
void CopyBits(u32 destBitOffsetu32 srcBitOffsetu32 stringLengthu32destu32src)
{
    
register u32 destBitOffsetReg asm ("r26") = destBitOffset;
    
register u32 srcBitOffsetReg asm ("r27") = srcBitOffset;
    
register u32 stringLengthReg asm ("r28") = stringLength;
    
register u32destReg asm ("r29") = dest;
    
register u32srcReg asm ("r30") = src;
    
asm("
        movbsu
        "
        
/* output */
        
"r" (destBitOffsetReg), "r" (srcBitOffsetReg), "r" (stringLengthReg), "r" (destReg), "r" (srcReg/* input */
        
);
}
#else
/* This works */
void CopyBits(u32 destBitOffsetu32 srcBitOffsetu32 stringLengthu32destu32src)
{
    
register u32 destBitOffsetReg asm ("r26") = destBitOffset;
    
register u32 srcBitOffsetReg asm ("r27") = srcBitOffset;
    
register u32 stringLengthReg asm ("r28") = stringLength;
    
register u32destReg dest;
    
register u32srcReg asm ("r30") = src;
    
asm("
        mov r29,r1
        mov %3,r29
        movbsu
        mov r1,r29
        "
        
/* output */
        
"r" (destBitOffsetReg), "r" (srcBitOffsetReg), "r" (stringLengthReg), "r" (destReg), "r" (srcReg/* input */
        
"r1""r29" /* clobbered */
        
);
}
#endif

I've noticed that DanB's Hunter engine follows this pattern as well-- backing up r29 before executing movbsu. My question is: why is this necessary? Is this a bug in gccvb? I read through NEC's official documentation for both the v810 and the v830 and with the exception of the bitstring instructions, neither designates r29 as a first-class citizen. I'm kinda stumped and would prefer the compiler to handle register assignments as it tends to be better at that than I am, especially when inlining.
Top

#2
Re: Is r29 treated specially / ignored by gccvb? (Bug?)
Posted on: 2010/11/19 7:14
VB Gamer
Joined 2008/7/19
35 Posts
Long Time User (11 Years) App Coder
Which version of gcc?
Top

#3
Re: Is r29 treated specially / ignored by gccvb? (Bug?)
Posted on: 2010/11/19 14:07
Nintendoid!
Joined 2007/12/14
169 Posts
CoderLong Time User (12 Years) App Coder
GCC 2.95.2, using the sources and patches from this site. (Is there a newer version that works better?)
Top

#4
Re: Is r29 treated specially / ignored by gccvb? (Bug?)
Posted on: 2010/11/22 1:22
Nintendoid!
Joined 2007/12/14
169 Posts
CoderLong Time User (12 Years) App Coder
Just an update:

I built GCC 4.4.2 using the experimental patches found here and not only does this not solve the problem, I'm now getting an error message when compiling the "working" version (not very helpful):

main
.cIn function 'CopyBits':
main.c:345errorr29 cannot be used in asm here

Hmmmm... Why not?
Top

#5
Re: Is r29 treated specially / ignored by gccvb? (Bug?)
Posted on: 2010/11/25 4:39
Nintendoid!
Joined 2007/12/14
169 Posts
CoderLong Time User (12 Years) App Coder
Finally solved this issue.

According to this page, it looks like the v850 uses r29 as the frame pointer and this likely carried over into the v810 patches. The frame pointer is useful for debugging but without a working debugger it's pretty pointless for VB dev. The easy fix is to build passing -fomit-frame-pointer as an argument to GCC. A more appropriate solution is to fix GCC to assign a register to the frame pointer that isn't already reserved for internal use by the v810. I chose r25.

I've attached patches for both GCC 2.95.2 and GCC 4.4.2. HTH.

Attach file:


zip r29patches.zip Size: 0.92 KB; Hits: 150
Top

#6
Re: Is r29 treated specially / ignored by gccvb? (Bug?)
Posted on: 2010/11/25 5:00
Nintendoid!
Joined 2007/12/14
169 Posts
CoderLong Time User (12 Years) App Coder
Replying to myself again...

Here's the final version of my routine for anyone interested:


void CopyBits
(u32 destBitOffsetu32 srcBitOffsetu32 stringLengthu32destu32src)
{
    
register u32 destBitOffsetReg asm ("r26") = destBitOffset;
    
register u32 srcBitOffsetReg asm ("r27") = srcBitOffset;
    
register u32 stringLengthReg asm ("r28") = stringLength;
    
register u32destReg asm ("r29") = dest;
    
register u32srcReg asm ("r30") = src;
    
asm volatile(""
        "movbsu"
        
"=r" (destBitOffsetReg), "=r" (srcBitOffsetReg), "=r" (stringLengthReg), "=r" (destReg), "=r" (srcReg/* output */
        
"0" (destBitOffsetReg), "1" (srcBitOffsetReg), "2" (stringLengthReg), "3" (destReg), "4" (srcReg/* input */
        
"memory" /* clobbered */
        
);
}

You'll need to apply another patch to GCC to build this-- again, a likely carryover from the v850 renames r30 to "ep" (element pointer). The v810 doesn't have an element pointer and gccvb partially acknowledges this; however there are still bits of code left that translate r30 to ep in the intermediate assembly code, leading to errors at build time. I applied a quick patch (attached) that adds ep as a recognized register name mapped to r30, though a better solution would probably be to clean up any remaining references to the ep register.

Attach file:


zip r30patches.zip Size: 0.98 KB; Hits: 153
Top

 Top   Previous Topic   Next Topic


Register To Post