As indicated, for the next release (v0.0.13) I will be adding code to Campy to compile callvirt and box/unbox CIL instructions. Right now, compilation of callvirt actually calls only the base class method. For virtual functions to work (and, actually, a computed “late-bound method on an object”), the JITed code must be stored in the BCL meta. Then, for a callvirt, a pointer corresponding to the virtual function is loaded and called for the object. For box and unbox, I currently have an implementation of box for Int32, but will add in the other basic value types. Unbox will not be in this release–too much other work to do. It will probably take a couple weeks to get all this working.
But, with these changes, an ever larger amount of C# and NET framework should start to work as expected on a GPU. However, I have noticed many functions in the DNA runtime that are attributed “[MethodImpl(MethodImplOptions.InternalCall)]” which do not have a C++/C implementation. Clearly, DNA has some shortcomings that need to be fixed. I will deal with these missing methods first on a case-by-case basis. Then, at some point, a methodical check must be done to verify that there is an implementation for all such methods.
4 thoughts on “Next: Virtual functions and boxing”
Could campy be used to create a static library in c# that can be compiled together with code created in c++? I’m interested in trying to use campy as an easier language to write plugins for a core system written in cuda c/c++
At the moment, no. Campy’s main call to JIT is a For() call, which also performs a kernel call on the GPU. In addition, it assumes a DotNetAnywhere representation for arrays, and a C# lambda target struct as the main parameter to a kernel. However, it seems like an important use case. I’ll work on it at some point this summer. -Ken
Any updates on this use case?
Yes, the code is in, version 0.0.15, but it may be fragile due to finding what code to compile. Boxing and virtual functions are used for example in System.Console.WriteLine() calls, when printing different types. Currently, I’m redoing the CUDA base layer that Campy calls (CUDA version 10 broke SWIG, and so I’m forking and enhancing ClangSharp), and will get back to straight Campy issues (performance, code for finding assemblies still fragile, standalone compiler, daily builds, etc.) next week or so.