|
From: | Marco Manfredini |
Subject: | Re: [DotGNU]Melody |
Date: | Mon, 06 Aug 2001 15:45:30 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801 |
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 shouldinstead launch a low-urgency DotGNU project to1. 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
[Prev in Thread] | Current Thread | [Next in Thread] |