Re: JVM as UNCOL, was ANDF/TDF

David Chase <David.Chase@naturalbridge.com>
13 Oct 2001 23:09:23 -0400

          From comp.compilers

Related articles
Re: JVM as UNCOL, was ANDF/TDF joachim_d@gmx.de (Joachim Durchholz) (2001-10-06)
Re: JVM as UNCOL, was ANDF/TDF gmc444@yahoo.com (2001-10-10)
Re: JVM as UNCOL, was ANDF/TDF joachim_d@gmx.de (Joachim Durchholz) (2001-10-12)
Re: JVM as UNCOL, was ANDF/TDF asunil@csa.iisc.ernet.in (Sunil Kumar Anand) (2001-10-12)
Re: JVM as UNCOL, was ANDF/TDF jesper@zuschlag.dk (Jesper Zuschlag) (2001-10-13)
Re: JVM as UNCOL, was ANDF/TDF jesper@zuschlag.dk (Jesper Zuschlag) (2001-10-13)
Re: JVM as UNCOL, was ANDF/TDF David.Chase@naturalbridge.com (David Chase) (2001-10-13)
Re: JVM as UNCOL, was ANDF/TDF joachim_d@gmx.de (Joachim Durchholz) (2001-10-13)
Re: JVM as UNCOL, was ANDF/TDF vbdis@aol.com (2001-10-13)
Re: JVM as UNCOL, was ANDF/TDF fjh@cs.mu.OZ.AU (2001-10-16)
Re: JVM as UNCOL, was ANDF/TDF fjh@cs.mu.OZ.AU (2001-10-16)
Re: JVM as UNCOL, was ANDF/TDF joachim_d@gmx.de (Joachim Durchholz) (2001-10-20)
Re: JVM as UNCOL, was ANDF/TDF vbdis@aol.com (2001-10-20)
[4 later articles]
| List of all articles for this month |

From: David Chase <David.Chase@naturalbridge.com>
Newsgroups: comp.compilers
Date: 13 Oct 2001 23:09:23 -0400
Organization: Compilers Central
Keywords: C++, Java, UNCOL
Posted-Date: 13 Oct 2001 23:09:23 EDT

Sunil Kumar Anand wrote:


> The question of porting C and C++ does not arise at all because C and
> C++ have pointer accessses which Java does not allow at any cost.


It can be done -- simply allocate an array, and that is your memory.
Everything proceeds, tediously, from there. There is a performance
penalty; not the worst I can imagine, but definitely a penalty.
There's also numerous optimizations that could be made along the way
in the transformation of C into Java. Dealing with function pointers
is probably the severest crock, but there's always reflection (think
separate I and D spaces -- D-space is an array of "words", I-space is
an array of java.lang.reflect.Method.)


So, possible, at a cost.


> Regarding aothers,the eficiency has been the prime
> consideration. Java Bytecode(which is what Java Programmers call class
> files) was designed for interpretation.


I don't know that this was the original intent, and in any case,
it is perfectly well possible to compile it statically, to massage
it to some other intermediate form in a pre-installation step, or
to attach helpful "attributes" to the various classfiles. There's
multiple existence proofs that Java bytecodes can be compiled
statically (my employer sells one of them).


> Just like Java has Bytecode, C# has MSIL(Microsoft Intermediate
> Language). That's how .NET supports multiple languages on its
> platform.
>
> MSIL instruction is designed in such a way that it is easy to JIT
> compile rather than interpret.


Again, the notion of "intent", versus the effect of the intent. There's
not sufficient room for improvement, in terms of compilability, for
the intent to matter much. There are certain glitches that are
generally overcome in a cheap fashion (and "generally cheap" is
what optimizing compilation is all about).




David.Chase@NaturalBridge.com
1-617-484-1389


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.