Re: [DotGNU]__gc arrays

[Alex Stephens]

On Thu, 22 Apr 2004 07:51:24 +1000, Rhys Weatherley wrote:

> Doing the managed bits of C++ is not difficult, as it is just C# bolted onto 
> the side of C.  But the unmanaged bits will be very hard.
> 
> > I think the Mono team are working on one...
> 
> Do you have a URL for this?
> 
I read the following on Miguel de Icaza's web log at 
http://primates.ximian.com/~miguel/archive/2004/Apr-15.html

<quote>
15 Apr 2004: Another Anonymous Methods Code Drop (Permalink)

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.
</quote>