It would be very cool to use nvopencc to perform source-level analysis or transformations. So far, I’m getting build errors; the directory src/be/bec seems to be empty.
I also experimented with nvopencc compiler. I managed to build it from the sources available at svn.open64.net (NVISA target) and added some useful
intrinsics not available from CUDA… There was a number of compile errors: in fact, it concerns with expanding floating-point operators - some of them are just not implemented… ((
so I had to reimplement them by analogy with other operators. Up to now the compiler works pretty well with CUDA 2.1
I probably don’t have the hacking skills you do; would you mind sharing? If you’ve already integrated your code and don’t want to share it, I’d appreciate an email; I’d be happy to fix the compile errors only.
./table < OPTIONS.P
./table INTERNAL ERROR: didn't find name F F self
Is this related to the float problems you fixed?
I had to make the same modification to osprey/linux/make/gcommondefs as noted at http://forums.nvidia.com/index.php?s=&…st&p=540481, then made a new 64-bit compile directory with Makefile.platform from nVidia’s sources, and copy the “build” directory from nVidia’s sources.
hmm… this might be because I installed mcpp… will update this thread if I find out.
edit: no, it’s not mcpp…
edit2: any help would be much appreciated… this table thing is very annoying… I hate it when C programmers try to rewrite standard library features… all this annoyance for some command line parsing code.
I copied the nvopencc to a repository [link] if anyone is running into my initial compile problems (I’m building in src/targia3264_nvisa).
I think be/bec is an optional tool, therefore, when I fix the table problem, I’ll try commenting it out of the makefile…
I did finally get it to compile… I’m still not sure what the problem with table.c was. I ended up reinstalling suse… the link in the prev. post now seems to build for me (64 bit).