Back in October 2017–which seems so long ago, but has been only 8 months–I was looking around for a NET runtime to use for Campy. It was apparent that in order to support C# on a GPU beyond value types, I was going to need a NET framework runtime. Why? It turned out there were many calls into C code, which depended on what runtime the program was compiled against. Even if you ignore this, you still need a meta on the C# side of Campy in order to get the size and alignment of fields in value and reference types when you allocate and copy objects from the CPU to GPU. The JIT compiler has this sort of baked into the code already, but it still needs to be formally added.
So, like any good programmer, I looked around. What I found were big, bloated packages: Mono, CoreCLR, etc. The NET framework that Campy needed I assumed would be a very small substituting layer for only the lowest layer of classes. Understand that GPUs don’t have file IO, don’t have threads in the classic OS sense, and many other things. So, the assumption here is that the lowest level layer isn’t changing, and hasn’t changed for a long time. Therefore, any class that uses the lowest level layer isn’t going to have problems calling into that layer because it is probably the same everywhere. Whether this assumption remains valid only time will tell. And, I can always use one of those bloated frameworks if my assumption is incorrect. But, there were greater problems–like writing a compiler for CIL, so I went fishing.
I came across an article in CodeProject, DotNetAnywhere: An Alternative .NET Runtime. Despite it not being modified for six years, I was heartened to learn that another project called Blazor was using DNA. (I learned a few months ago that Blazor switched to Mono two weeks after the CodeProject post.) So, I decided to port DotNetAnywhere (DNA) to CUDA. That turned out to be not terribly hard, but then I discovered the really big problems: DNA does not work in 64-bits, and there are quite a few bugs in reading the metadata tables. While I congratulate Chris Bacon for writing a good tool, DNA has a lot of problems. I fixed the code so that it runs on a 64-bit target. But, if an assembly contains metadata tables that aren’t supported by DNA, it craps out. And, I just found out that if I declare a field as an array of System.Numerics.Complex, DNA says the type of the field is an SByte!
At this point, I’m kind of committed to using DNA for Campy. I will be fixing the code that reads PE files, including code to read all tables in the ECMA 335 spec, and parsing the signature blobs robustly. I will also be writing a tool to read and output in a human readable format NET assemblies, similar to DotPeek, but with output to stdout so it can be used as a regression tool. As an old coworker said long ago about software: sometime you just have to pound it into submission.
