Re: [DotGNU]Melody

[Marco Manfredini]

Norbert Bollow wrote:
> I'm still trying to digest this... do I understand this correcty
> that instead of making gcc compile to Java bytecode or the
> Intermediate Language defined in Microsoft's specs, we should
> instead launch a low-urgency DotGNU project to 
>
> 1. Invent a new intermediate language (probably incorporating
>    the "bytecode" ideas that have been discussed on the arch list)
>    that can be called Melody.

Yes. A high-level intermediate language which preserves information 
about dataflow, object lifetime and expression structures. These 
informations can be used to apply code transformations, global 
optimization, inlining between different compilation units. I also 
think, that support for automatic instantiation for generic types and 
functions can be included. Superior stuff. bytecode approaches have to 
reconstruct these informations before they can do this.

> 2. Expand GCC so that it can compile from all its supported
>    languages to Melody-based Portable Executables.

No. But I am also pessimistic concerning attempts to modify GCC to 
compile its supported languages into Java and/or IL.  Rhys describes the 
problems with the adaption of RTL to a pure stack machine. The paper 
from the COBOL team says the same. The gcj frontend is in fact nothing 
more than a front-end: it doesn't even try to pass its output to RTL. 
The gcc backend AFAIK doesn't preserve signatures, types etc. But these 
informations are required to generate JavaVM or IL Modules. Another 
example: Java VM and IL have builtin support for exceptions, this 
support must work with C++ exceptions, or the C++ support would be 
questionable. But how can I tell in the RTL phase, that a given code 
fragment is part of a scope cleanup? If I can't tell, then I cannot 
generate Java or IL code which integrates the scope cleanup into the 
exception model of the target machine code. Another bad thing: GC!

Anyway I am not competent in this matter and I'd like to hear from the 
gcc people what they think about that. They are the ones that know.

IMHO Melody cannot be generated from a backend, as well as Java and IL. 
An working implementation of any of these must somehow set a tap between 
the language and the RTL.

> 3. Make the DotGNU platform support Melody-based Portable
>    Executables as a third portable executable format in
>    addition to the two portable executable formats (those based
>    on Java bytecode and IL) that we already want to support.

No. The idea is to make Melody strong enough to generate Java or IL if 
required, thus requiring only one portable executable format for all 
times. And since it is a machine and language independent format, which 
describes the expression structure [compareable with the AST phase of a 
compiler] and not with registers or stacks, it should be even easy to 
implement the transformations to Java or IL. This is another benefit of 
not using a bytecodes: Imaginge you'd have to convert IL to JavaVM or 
vice versa. Difficult task.

But the main application of Melody is IMHO to generate applications from 
 Melody-units (Since I like with musical terminology so much, because 
of the correspondence between music and code, allow me to call "a unit 
of melody code" a tune). So we take tunes, put them together into a 
nifty optimizer and inliner, create one large tune and feed it into the 
gcc backend which generates optimized code for a machine.


Greetings
Marco