Re: JVM as UNCOL, was ANDF/TDF

Lex Spoon <lex@cc.gatech.edu>
20 Oct 2001 21:47:29 -0400

          From comp.compilers

Related articles
[7 earlier articles]
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)
Re: JVM as UNCOL, was ANDF/TDF lex@cc.gatech.edu (Lex Spoon) (2001-10-20)
Re: JVM as UNCOL, was ANDF/TDF chase@world.std.com (David Chase) (2001-10-23)
Re: JVM as UNCOL, was ANDF/TDF marcov@toad.stack.nl (Marco van de Voort) (2001-10-28)
Re: JVM as UNCOL, was ANDF/TDF alexc@world.std.com (2001-11-04)
| List of all articles for this month |

From: Lex Spoon <lex@cc.gatech.edu>
Newsgroups: comp.compilers
Date: 20 Oct 2001 21:47:29 -0400
Organization: Georgia Institute of Technology
References: 01-10-063
Keywords: OOP, Java
Posted-Date: 20 Oct 2001 21:47:29 EDT

David Chase <David.Chase@naturalbridge.com> writes:


> 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.)




It doesn't have to be reflection methods. You can simply have objects
of class "CFunction" with a single invoke() method.


Now, the question everyone is avoiding, is whether *real* C programs
will work under this regime, not just strict ANSI C programs. :) I've
thought about this problem in another context, and my guess is that
you will want to use an array of words implementation even though it's
cleaner to represent pointers as array-plus-offset. And don't forget,
by the way, that the C stack needs to be in that array, too, so that
pointers to stack-allocated variables will work correctly.


Overall, one ends up turning the tables and writing a *C* interpreter
in *Java*. Among other things, please notice that the C code will
always be slower than "native" Java code. <g>


-Lex


Post a followup to this message

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