[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Melody

From: Marco Manfredini
Subject: Re: [DotGNU]Melody
Date: Tue, 07 Aug 2001 09:47:34 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801

Norbert Bollow wrote:
> I believe that the set of supported languages in which you can
> write applications for the DotGNU platform should definately
> include C and C++, and one of the big open questions is how to
> best achieve this.  Compiling (directly or indirectly) to IL
> may or may not be the best strategy.

Btw. I fear that M$ messed things hugely up with their
CLR. For example I recently found out, that making a C++ class managed (__gc), changes their constructor semantics, i.e. a virtual call during base class construction calls the method from the derived object, which isn't initialized yet, like in Java and C#. This is dangerous, but typical how M$ treats standards: they mistreat them)

I'd bet that direct translation into IL will require more changes to the compiler.

>>* Every dotGNU language can compile to Melody.
>>* Every Melody can be compiled into IL.
>>* Every Melody can be compiled into JavaVM.
> Why compile Melody to *two* bytecode formats???  Sounds like
> unneccessary effort in terms of compiler code that would need to
> be written and maintained!?
This decouples a language compiler from the back-end. It should make work simpler indeed, since a new compiler has to support only one back-end language (Melody). And the implementor of a translator from Melody to something else would not need to fear that he'd break one of the supported front-end language, because he has only to follow a cleanly defined interface (i.e. an abstract language which has easy semantics).

So if we want to support compilation to JavaVM, we write a mapping between Melody and Java. If somebody doesn't like the idea to interpret bytecodes of wrong endianess on his PDA, he writes a trivial (but space efficient) Melody to machine language converter.

This should also encourage the maintainers of languages outside of the gcc collection to create a port to a Melody backend. And making a Language=>Melody translator should be save a lot of work, because you don't have to mud into the low-levelness to a bytecode machine (stacklayout etc.) anymore.

The looks like extra work in the first place, since there are many existing language ports for Java for example. But how do we get these Java Ports to run onto IL? JavaVM code and IL code cannot interoperate because they are tied to their language runtime. Or can they?

Greetings, Marco

reply via email to

[Prev in Thread] Current Thread [Next in Thread]