[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 16:23:36 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801

Mike Hoolehan wrote:
> On (07/08/01 09:47), Marco Manfredini wrote:
>>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.
> If Melody can be described as a machine-independent intermediate language
> that preserves semantic information about the original code, couldn't it
> also just be described as another programming language?

Not if you would call machine-language (not assembler) a programming
language. Melody would be code, in the sense that it consist of binary
tokens which had a unique and non-ambigous meaning. Compare this to C where for example the operator + is /polymorphic/ since it works with different types, involves coversions etc..its the job of the compiler to figure out what "+" means according to the language rules.

It could be converted to a text representation which would reveal that the codes in fact describe a structure. This is the difference from JavaVM where "structure" exists only in the description of the class, but no more in the byte-codes (these are just codes, and you'd have to reconstruct block scopes or loop). In that sense, Melody would be a structured higher-order machine-code.

> When it's said that all dotGNU supported languages must be translated into
> Melody, which can then be translated into perhaps Java Bytecode or IL,
> aren't we really saying that dotGNU only supports the Melody programming
> language and that to use another langauge someone (GNU) will need to write a
> translator from the source language to Melody?

No the schema is this:

Lang1 -------\            /------ JavaVM
              |           |
Lang2 --------|           |------- M$-IL      /---- i386-hurd
              |---Melody--|                  /
Lang2 --------|           |------- GCC------------ m68k-linux
              |           |                  \
Lang3 -------/            \------- Y*         \---- mips-elix

Y* are other backends that destiny makes us support. "GCC" means,
that GCC understands Melody-code and translates it into machine-code for
a platform. Lang[1-3] are languages that should run on every platform
that can be generated from Melody.

> Sorry to speak in questions, but I'm not sure of my understanding of Melody.
> dotGNU could just as easily say that Java, for instance, is that
> machine-independent language that preserves semantic info. Saves the work of > inventing a new language. I don't truly think this is a good idea, by the
> way, just making a point.

I think that just JavaVM won't really alltogether work. The design of the JavaVM had Java in mind. It executes what Java describes. This means that other languages need to take funny circumventions to implement their semantics. For example, Java has no "pointers", it has references which *can only* point to class instances.

Now, map C or C++ to JavaVM. Or any other language that has pointers.

Now, write a JIT which can reconstuct the pointer-hacks you've made into
real pointers!

M$-IL is "richer", since it was designed with more languages in mind,
but (as I've said somnewhere before), the CLR requires changes to the
language semantics, which had to be hardcoded into the compiler. Into each compiler. But I'm convicted that a intermediate language which provides sufficent information about the expression structure could provide what the translator to M$-IL would need to support the operation of the output under M$-CLR.

> A separate point: if Melody is used, perhaps an xml-based syntax would be
> beneficial.

Yes, I think that Melody could have homomorphic representations, the
binary representation would exist for fast machine operation, compressed
  storage and distribution, while structural equivalent XML
representation could be used for high-level queries, database storage,
browsing etc with XML processing tools.

It wouldn't make a difference for the dotGNU tools, because it's just a matter of the reader/writer library they'd use. Sensible design practice, separate processing from I/O.

Greetings, Marco

reply via email to

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