|Re: C -> Java Bytecode firstname.lastname@example.org (1999-08-01)|
|Re: C -> Java Bytecode email@example.com (1999-08-02)|
|Re: C -> Java Bytecode firstname.lastname@example.org (1999-08-04)|
|From:||email@example.com (Mohd-Hanafiah Abdullah)|
|Date:||1 Aug 1999 23:04:53 -0400|
|Organization:||MIMOS BERHAD, MALAYSIA|
|Keywords:||C, Java, GCC|
Trent Waddington <firstname.lastname@example.org> wrote:
>Hi.. I'm currently working on a gcc backend to produce java bytecode
>from lowlevel c input files (which are the intermediate language of a
I have been thinking about the same thing, i.e., targeting C source to
the JVM. Maybe we could get into the discussion of how feasible this
kind of effort could be. For one thing there's a lot of C code out
there that could benefit from recompilation to Java bytecode.
Maybe the following points could be considered in order to enhance the
practicality of the retargeting effort in order to be widely accepted:
1. Strictly C source translation to bytecode (no assembler code).
2. C source code must be POSIX compliant for UNIX platforms.
3. C source code must be compliant to Windows API standard/convention for
4. Port all standard C libraries to Java bytecode.
5. Have access to third party library source code in C one way or another
to port to bytecode; if it's not already available in bytecode.
6. JVMs/JiTs and CPUs are getting better all the time to address the
performance issue, hopefully.
The issue of Java's sandbox concept, transparent memory architecture, and
others related to Java security need to be addressed.
I would guess this TOOL shouldn't be viewed as the answer-to-all C
port to JVM problems. It could very well be seen as addressing a
hopefully large niche market. It is a fast-track porting of C
applications to the increasingly popular JVM without having to go
through the cumbersome and error-prone source-to-source translation.
Return to the
Search the comp.compilers archives again.