I only have brief experience with .NET, but I had the idea that it might be possible to tell NVCC to compile C code straight to MSIL just by passing the /clr switch to visual c++. This code would then be completely cross-platform, able to run on Linux and Mac OS, via Mono.
Has anyone tried this?
I think the way you ‘talk’ to the driver is different on each platform, or not? This sounds a bit too easy to be true ;)
But what about a different question: can you compile “nvcc /clr” and create simple (windows-only) C# bindings without messing with P/Invoke, GASS, etc.?
E.D. Riedijk is right…you’d need to know how to access the driver on each platform.
Also, MSIL doesn’t “know” how to access any underlying system hardware, etc. It’s simply an intermediary language; when you write a .NET program and compile it, the executable has a header that tells the operating system that it is an MSIL program, and needs to be passed to the .NET framework JIT compiler, which then takes the MSIL code and compiles it to native code (which is able to access the system’s hardware).
alex, an alternative method is to find a program that can read a DLL (or parse C source code for a DLL) and generate a C# class that acts as a wrapper for the class (and takes care of all the P/Invoking and marshaling). I’ve heard that Microsoft has a free tool out there that does this, but I haven’t searched for it. If you can find it, it might make your life a bit easier.
EDIT: I do a majority of my development for the .NET platform, so I’ve been stuck doing my CUDA work via P/Invoke for a while now…
C++/CLI automatically generates P/Invoke logic, which is what’s cool about it. (No need for third-party tool. Just make a managed ‘ref’ class and make ordinary C++ calls in it.)
Regarding portability: How does P/Invoke translate across platforms?
P/Invoke should translate just fine across platforms…you’ll just need to have the .NET framework installed (if you want to run on a Windows box) or the Mono Framework (if installing on Linux/BSD/Mac OS X). The underlying framework will take care of whatever needs to be done to P/Invoke a DLL on that platform.
However, I don’t know if that will let you create a portable CUDA executable, since you won’t be able to P/Invoke the CUDA driver on a non-Windows platform (since it won’t be using a DLL).