C++ to JVM compiler
 

There used to be an alpha quality JVM backend for RedHat's branch of
GCC, but it was abandoned, because FOSS luminaries did not approve of
Java (strange, because both are out to crush Microsoft)

Now that Java is going open-source again, I hope this project will be
resurrected. C++ and Java are the most widely used languages. It's a
shame that C++ can not be compiled to JVM, even though there is a ton
of platforms that it can be compiled to, and there is a ton of
languages that do compile to JVM.

Let me list the advantages:

* definitively determine memory corruption caused by a C++ program
(valgrind and VC++2005's debug mode help, but can not always detect
it; also they are much slower than JVM; it would also be nice to be
able to detect uninitialized memory access, but I don't think JVM can
help with that, since it has everything initialized)

* call C++ programs more easily from Java, presumably

* run C++ on some exotic platforms with JVM and no C++ compiler (rare)

* run some C++ code faster (Java sometimes beats C++ on numerics-heavy
tests - currently rare, but things seem to be changing in favor of
JIT)

* run C++ safely - I know there are arrogant C++ coders who would
claim that their C++ code can not be exploited, but is there an
automated way to prove that?

(This could make a great summer-of-code project, unless it's too hard
- I don't actually know)

Re: C++ to JVM compiler
 

On Apr 24, 2:03 am, Razii <whatever1...@hotmail.com> wrote:
> On Thu, 24 Apr 2008 01:50:35 -0700 (PDT), "jhc0...@gmail.com"
>
> <jhc0...@gmail.com> wrote:
> >Now that Java is going open-source again, I hope this project will be
> >resurrected. C++ and Java are the most widely used languages. It's a
> >shame that C++ can not be compiled to JVM, even though there is a ton
> >of platforms that it can be compiled to, and there is a ton of
> >languages that do compile to JVM.
>
> http://nestedvm.ibex.org/
>
> NestedVM provides binary translation for Java Bytecode. This is done
> by having GCC compile to a MIPS binary which is then translated to a
> Java class file. Hence any application written in C, C++, Fortran, or
> any other language supported by GCC can be run in 100% pure Java with
> no source changes.


Very interesting. Although, for C++ debugging, I don't think this
approach would always work for memory corruption detection, e.g.

#include <iostream>

struct pr {
double x;
double get_y() const { return y; }
pr() : x(0), y(0) {}
private:
const double y;
};

int main() {
pr p;
(&p.x)[1] = 3; // write to const private y
std::cout << p.get_y() << '\n';
}

Re: C++ to JVM compiler
 

jhc0033@gmail.com wrote:
> Now that Java is going open-source again, I hope this project will be
> resurrected. C++ and Java are the most widely used languages. It's a
> shame that C++ can not be compiled to JVM, even though there is a ton
> of platforms that it can be compiled to, and there is a ton of
> languages that do compile to JVM.

Any C++-to-JVM compilation would have to be imprecise and rely on
several heuristics. Pointer arithmetic, rather common in C++ code, does
not convert to JVM bytecode well. Quirks of templates in C++ make
conversion to Java generics near impossible unless Java gains
reification. Finally, any crazy stuff I could do with function pointers
would not translate well.

> * run some C++ code faster (Java sometimes beats C++ on numerics-heavy
> tests - currently rare, but things seem to be changing in favor of
> JIT)

This is a large bone of contention, but the two languages are more or
less equally fast these days. Likely the C++ code would be slowed down
as some imprecise translations would use hackier crutches.

> * run C++ safely - I know there are arrogant C++ coders who would
> claim that their C++ code can not be exploited, but is there an
> automated way to prove that?

GCC dehydra? <http://wiki.mozilla.org/Dehydra_GCC>. Of course, you have
to write the tests first.

> (This could make a great summer-of-code project, unless it's too hard
> - I don't actually know)

I am not an expert in this area, but I think it would be on the harder
side. The GSoC application time frame for 2008 has already passed, though...

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Re: C++ to JVM compiler
 

On Apr 24, 2:40 pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:

> Any C++-to-JVM compilation would have to be imprecise and rely on
> several heuristics. Pointer arithmetic, rather common in C++ code, does
> not convert to JVM bytecode well.

A pointer into an array, for example, is just a pair of
* array (reference)
* index into it
when the pointer points outside of the array the behavior is undefined
in C++, so I would like the Java version to fail in a case like that.

> Quirks of templates in C++ make
> conversion to Java generics near impossible unless Java gains
> reification.

Templates shouldn't be translated into generics. C++ templates are
semantically closer to C++ macros than to Java generics.

> Finally, any crazy stuff I could do with function pointers
> would not translate well.

I don't see any difficulties there either.

> > * run some C++ code faster (Java sometimes beats C++ on numerics-heavy
> > tests - currently rare, but things seem to be changing in favor of
> > JIT)
>
> This is a large bone of contention, but the two languages are more or
> less equally fast these days. Likely the C++ code would be slowed down
> as some imprecise translations would use hackier crutches.

For debugging, anything less than a 10x slow-down would beat MSVC++
debug mode, and anything less than a 100x slow-down would beat
valgrind.

> > * run C++ safely - I know there are arrogant C++ coders who would
> > claim that their C++ code can not be exploited, but is there an
> > automated way to prove that?
>
> GCC dehydra? <http://wiki.mozilla.org/Dehydra_GCC>. Of course, you have
> to write the tests first.

Not sure what it can do for me, but thanks for the link. I don't write
utterly bad C'ish C++ with strcpy, etc. However, I once spent days if
not weeks looking for an uninitialized value usage bug.

Re: C++ to JVM compiler
 

"jhc0033@gmail.com" <jhc0033@gmail.com> writes:
>I don't see any difficulties there either.

Java has a 64 KByte limit for the size of methods.

http://bugs.sun.com/bugdatabase/view...bug_id=4262078

So a C++ function can not be translated to a Java method
(except for the case that it will not exceed 64 KBytes).

Re: C++ to JVM compiler
 

Stefan Ram wrote:
> "jhc0033@gmail.com" <jhc0033@gmail.com> writes:
>> I don't see any difficulties there either.
>
> Java has a 64 KByte limit for the size of methods.
>
> http://bugs.sun.com/bugdatabase/view...bug_id=4262078
>
> So a C++ function can not be translated to a Java method
> (except for the case that it will not exceed 64 KBytes).
>
Anyone who writes methods bigger than 46K should be looking for another
line of work..

--
Ian Collins.

Re: C++ to JVM compiler
 

Stefan Ram wrote:
> "jhc0033@gmail.com" <jhc0033@gmail.com> writes:
>> I don't see any difficulties there either.
>
> Java has a 64 KByte limit for the size of methods.
>
> http://bugs.sun.com/bugdatabase/view...bug_id=4262078
>
> So a C++ function can not be translated to a Java method
> (except for the case that it will not exceed 64 KBytes).
>

I'm sorry, but I don't see why this particular limitation of the JVM
limits what sort of C++ can be compiled to JVM code.

Is there some limitation in the JVM that prevents turning a single
method into a number of methods that are functionally equivalent to the
single method?

LR

Re: C++ to JVM compiler
 

LR wrote:
> Is there some limitation in the JVM that prevents turning a single
> method into a number of methods that are functionally equivalent to the
> single method?

I don't think I'd call it a limitation of the JVM, but of automatic
language translations in general. It can be very hard to perform such
a split while preserving the original semantics and keeping the
efficiency close to what was there originally. Remember that you'd
like such a process to work correctly on the pathological cases as
well as the simple ones.

--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.

Re: C++ to JVM compiler
 

Steve Wampler <swampler@noao.edu> writes:
>I don't think I'd call it a limitation of the JVM, but of
>automatic language translations in general. It can be very
>hard to perform such a split while preserving the original
>semantics and keeping the efficiency close to what was there
>originally. Remember that you'd like such a process to work
>correctly on the pathological cases as well as the simple ones.

Scheme can be compiled to C or C++ using »trampolining«.

This will create one big function from the whole Scheme
program, like

while( running )
{ switch( programm_counter )
{ case 0: /* compiler output for a scheme closure */ break;
case 1: /* compiler output another scheme closure */ break;
case 2: /* and so on */ break; ... }}

Since the whole Scheme program is being compiled to one
large switch, this switch might be larger than 64 K.

Because (possibly small) closures are activated often,
one does not want to have a call overhead for each closure
activation.

Re: C++ to JVM compiler
 

On Apr 25, 3:14 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> Since the whole Scheme program is being compiled to one
> large switch, this switch might be larger than 64 K.
>
> Because (possibly small) closures are activated often,
> one does not want to have a call overhead for each closure
> activation.

The authors of Bigloo and Kawa would sure like to know that, because
of closures, their Scheme->JVM compilers are even MORE impossible
than C++ -> JVM.