[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
- Re: [DotGNU]Melody, (continued)
- Re: [DotGNU]Melody, Scott Lanham, 2001/08/06
- Re: [DotGNU]Melody, Marco Manfredini, 2001/08/07
- Re: [DotGNU]Melody, Norbert Bollow, 2001/08/07
- Re: [DotGNU]Melody, Marco Manfredini, 2001/08/07
- Re: [DotGNU]Melody, Scott Lanham, 2001/08/07
- Re: [DotGNU]Melody, Marco Manfredini, 2001/08/07
- Re: [DotGNU]Melody, Scott Lanham, 2001/08/07
- Re: [DotGNU]Melody, Norbert Bollow, 2001/08/07
- Re: [DotGNU]Melody, Norbert Bollow, 2001/08/07
- Re: [DotGNU]Melody, Mike Hoolehan, 2001/08/07
- Re: [DotGNU]Melody,
Marco Manfredini <=
- [DotGNU]Architecture Neutral Distributed Format., Hans-Olof Danielsson, 2001/08/07
- Re: [DotGNU]Architecture Neutral Distributed Format., Rhys Weatherley, 2001/08/07
- Re: [DotGNU]Architecture Neutral Distributed Format., Marco Manfredini, 2001/08/08
- Re: [DotGNU]Melody, Barry Fitzgerald, 2001/08/09
Re: [DotGNU]Melody, Scott Lanham, 2001/08/08