Re: JVM as UNCOL, was ANDF/TDF

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

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