Gobaan_Raveendran@xxxxxxxx writes: > I am a student working on a porting gcc to an embedded architecture, and > one of the key requirements for this is named address space support as > stated in the Embedded C standard. > > Fortunately, Ben Elliston of IBM recently implemented these for the SPU in > two steps, as stated in the following two patch requests: > http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01361.html - Front-End > link [at the time of this writing attempting to view his original post > causes a file not found error] > http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01479.html - Back end > link > > I have three questions: > 1. Using ViewVC we can look at the branch and most files are documented > with " Merge with mainline.". So I checked out the trunk, but the changes > were not present. I am wondering if I did > something wrong, and there is a later snapshot (that may be stable?) that I > should have checked out that does have these changes integrated. Ben has not commited his changes to mainline yet. For that matter, I don't think they've been approved. The comments "merge with mainline" indicate a merge from mainline onto the branch. > 2. As I am new to developing/reading gcc code, and I have been reading a > lot of the documentation, I was wondering if there is any standard place > for documentation on retargetting gcc for different architectures, > specifically if there would be a place where it would tell me how to > implemented additional address spaces, as well as what conflicting > qualifier checking is implemented. Currently I am reading > http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals and I do not expect > named address spaces to be documented much because they have been in gcc > for about three weeks, but any help will be useful. Any documentation that Ben has written would be in the patch itself, not anywhere else on the web. > 3. Since the trunk did not work, I checked out the named_address_space > branch, built it, newlib, binutils etc. and eventually got it compiling SPU > code. However, it crashes on the following code > that I modified from an IBM tutorial. > > /* pointer in PPU address space pointing to PPU address space */ > extern __ea int * __ea p; > int main(unsigneng long speid, unsigned long long argp, unsigned long long > envp) > { int x = * ((int *) p); return x; > } > > Causes: > spu-gcc -Wall -otest.o test.c > /usr/local/lib/gcc/spu/4.4.0/libgcc_cachemgr.a(cachemgr.o): In function > `__cache_miss': > PATH-TO-GCC-SOURCE/gcc/config/spu/cachemgr.c:301: undefined reference to > `__ea_local_store' > PATH-TO-GCC-SOURCE/gcc/config/spu/cachemgr.c:305: undefined reference to > `__ea_local_store' > collect2: ld returned 1 exit status > > This is likely because it cannot determine if the __ea pointer is in SPU > memory, but I was just wondering if this reveals a deeper error, as it is > detecting that a variable in gcc's source is undefined, in which case maybe > I should submit this to the gcc-patch/test suite. Then again, it could be > that I am using an unstable version, I did something else wrong or as long > as the error is detected it doesn't matter. This seems like an error in gcc/config/spu/cachemgr.c. Don't file a bug report though, since this is using a branch. Just e-mail Ben directly. He won't bite. Ian
