Another Anonymous Methods Code Drop

A fresh patch and a full tarball for MCS.

Managed C++

I read Anthony Green's feedback on using Open64 as the foundation for implementing a Managed C++ compiler. I respectfully disagree with his opinion.

Let me explain why Open64 is the best starting point for implementing Managed C++.

First, the requirements:

• A C++ compiler that can generate images in the Common Intermediate Language (CIL). The intermediate language for the ECMA 335 virtual machine.
  Essentially, any existing C or C++ code needs to be compiled into CIL code.
• Expand the language to include the Managed C++ extensions, in some cases the extensions might restrict what you can do.
• High level information must propagate to the low-level CIL layer to provide introspection capabilities, attributes, and become a full CLS consumer and producer.

Since C++ is a language of titanic dimensions, it is not one that you want to reimplement. Your best choice is to pick an existing C++ compiler. In the case of the free software community, that means gcc or any of its forks.

The question is whether GCC's internal IR can be retargetted to produce code for the stack-based CIL and whether you can propagate the extra available metadata. The later seems like a problem that we would have in both Open64 and gcc.

Now what makes Open64 interesting is the fact that we can achieve the first goal without touching GCC: C and C++ compilation would be performed with the Open64 compiler down to WHIRL and then a new generic WHIRL-to-CIL compiler is produced that generates the files we want. We do not have to mess or touch any of the existing GCC internals (it is a difficult code base to work with).

The above is very similar to IKVM's JVM to CIL compiler: the input "language" is an IR, the output language is a different IR.

The fact that Open64 does not target the x86 in a way is irrelevant, because we are not interested in targeting the x86. We are interested in targeting the CIL.

If we were to use the current GCC, we would have to intercept a good stage in the compiler, and most likely deal with RTL and produce bytecodes for CIL. The RTL is hard to penetrate and deeply linked to gcc internals. WHIRL is independent, well documented, and has various tools to process, consume and analyze the various WHIRL stages.

Finally there is the point of the FSF and the GCC maintainers refusing to make structural changes to GCC on philosophical grounds. A split that would encourage the creation of proprietary front-end and back-end systems.

Not only does this mean that its better to work with the Open64 fork of GCC which has already made this pragmatic decision and is a better foundation for targeting the CIL, but our goals are more aligned than those of the GCC maintainers.

Update: Open64

The latest version of Open64 folded in the changes from Intel and ICT.