[Mono-list] C++/CLI compiler

João Matos ripzonetriton at gmail.com
Sun Dec 9 04:36:26 UTC 2012


Hi.

So I've been working for a bit on a C++/CLI compiler and I think it's came
along enough that it makes sense to announce it.

I started it because of the need to interop with existing C/C++ native
code. I first tried extending Cxxi for a bit, but found some problems that
cannot be solved with the approach of generating IL code at runtime. So I
tried Microsoft's implementation C++/CLI and found it is a pretty nice
extension of C++ that makes it play nice on .NET and started implementing.
Since there is nothing like it for Mono (at least publicly), I started
working on a new implementation of it above the Clang and LLVM platforms.

The frontend (Clang) was extended to support the Ecma 372 (C++/CLI
standard) additions to the type system, expressions and declarations, like
handles, tracking references, CLI arrays, CLI properties and CLI generics.
It then uses Cecil to import the metadata from DLLs that are introduced in
the translation unit via #using.

LLVM was also extended with a CIL backend based on the old MSIL LLVM
backend. The old backend had some problems and had to be updated to compile
with the new LLVM interfaces. It also only generated IL code from native
code and had no support for calling .NET types. I later found out LLVM is
not really that suited to an higher-level assembly language like IL so I
also had to modify and extend Clang's IR gen to send some bits as metadata
(LLVM does not have signedness support on its integer types, for instance).
The backend at the moment generates ILasm text code that is assembled
externally, but long term I'd really like to emit IL directly via Cecil.

Here are some use cases where it might be useful:
 1. Calling .NET libraries from native C++ (via calls to the Mono runtime
for invocations)
 2. Compiling existing C++ code to CIL code (of course you can also call
.NET code in this case)
 3. Introducing new .NET types via pure CIL C++ code
 4. Calling native libraries from .NET types (seamless interop)

At the moment only use case 2. is implemented and fully functional, though
I am starting to work on the other use cases. 1. is especially important
for bootstrapping on Linux (see below).

Implemented CLI features:
 + Handles
 + Ref classes
 + Value classes
 + Properties
 + Indexers
 + Generics
 + Arrays
 + Parameter arrays (variadics)
 + Attributes (WIP)

Missing CLI features:
 - Exceptions
 - Delegates
 - Events
 - Static Constructors

So you can that there are still quite a bit of things left to implement and
some that are implemented need some love:

 - Diagnostics and error handling needs a bit of work to be robust. It has
not been tested that much yet.

 - The generated code is really crap at the moment, LLVM is not that well
suited to generate code for stack machines, but there are papers out there
with stack optimization strategies that can be implemented to improve on
this front.

 - The compiler still has a bit of a bootstrapping problem, as it uses the
existing MS C++/CLI to bootstrap. I don't expect this to be a big problem,
since once Mono code-gen mode is added you will be able to call existing
.NET libraries from native code (instead of generating IL) and it should
work well on Linux too.

 - It needs a linker to be able to compile multiple C++ translation units
into just one .NET DLL. The strategy here is not fully clear to me, but I
was thinking on using the newly-developed LLVM linker (lld) to do it, since
it seems the best way forward. Another option would be trying to use
il-repack.

Somebody interested in helping out? Or maybe in sponsoring some features?
There is a lot of work left to do :)

Code is up at https://github.com/tritao/clang. There is still quite a bit
of code left to commit so don't try to compile it yet. The rest of the code
should be up in a day or two, along with instructions on how to compile it.

-- 
João Matos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20121209/7238ef97/attachment.html>


More information about the Mono-list mailing list